Strategic Product Manager

Guest Book Review: “User Stories Applied: For Agile Software Development” by Mike Cohn

Stewart Rogers — Mon, 02 Nov 2009 13:37:52 +0000

by Jason Brett

As a I want so that .

Whether you are new to story-driven software development or have been managing products or development with user stories for a decade, “User Stories Applied: For Agile Software Development” (Mike Cohn) is a great read.

I’m personally new to writing user stories, so I dove into Cohn’s book from a relatively fresh perspective, and found the entire book highly digestible. Mr. Cohn makes no assumptions about the readers level of expertise or familiarity with Agile methods. At the same time, he writes in a way that gives the reader credit for being intelligent and purposeful.

The book is broken into 3 parts:

Part 1 covers the basics of user stories and so much more. Cohn goes into a well paced discussion of the roles of each member of the agile team at each step of the process. Not only does he dissect the stories themselves, commenting on size and scope of stories, but Cohn pays a great deal of attention to cataloging and working with an appropriate variety of user roles, working with user proxies, acceptance tests, and an exceedingly valuable chapter discussing guidelines of good stories.

Part 2 continues the examination of the user story from the perspective of estimating and planning, stepping deftly from release to iteration, taking care to discuss monitoring and measurement of the release and iteration’s progress.

Finally, in Part 3, the Cohn ties everything together with an in-depth example and a well organized discussion of a variety of topics that naturally emerge in a business environment when applying user stories to an agile development framework. He spends a chapter specifically on user stories with Scrum, and another excellent chapter on “A Catalog of Story Smells.” This chapter provides a great reality check for anyone trying to detect and deal with potential team challenges when user stories may seem to be at the center of the discussion.

What stands out to me most about “User Stories Applied: For Agile Software Development” is not only it’s apparent status as the definitive work on User Stories, but it’s effective introduction to Agile software development from the Product Management perspective. This is a book that I think exceeds its purpose in that regard.

I read this book as an experienced product manager who is new to Agile and Scrum. It has been an invaluable resource to me in that role. What I appreciate even more about Cohn’s work is that after reviewing the table of contents for this review, I can see myself re-reading the book annually (for at least for the next couple of years) and gleaning new insights to help strengthen my process and products.

No matter what your role in an Agile organization, be it product manager, product owner, scrum master or marketing manager, I suspect this book will provide significant insights into your company’s development process that can do nothing but serve you well.

Jason Brett is a Product Manager at Silverpop Systems, Inc, Founder of ProductCamp Atlanta, and currently sits on the board of the TAG Product Management Society. Jason should blog at his own website http://www.jasonbrett.me, but rarely does. You can, however, follow him at http://www.twitter.com/jbrett. Be sure and leave an @ reply to say hi!

If you enjoyed this post, please leave a comment or subscribe to the feed to receive future updates. You can also follow me on Twitter. Tell other people about this post.

November… already? And Random Bits

Stewart Rogers — Sun, 01 Nov 2009 22:53:05 +0000

Next thing you know it has been 23 days since your last post. Oddly my subscribers have risen. Thanks for reading! There is lots going on in my life and reading and writing has sadly slipped below my capacity to process. I am hopeful that will change in November, but my travel schedule for the month is already pretty full. We shall see. Generally when I am lost for blog ideas I have a book review to do, but the current book (How We Decide by Jonah Lehrer) is a bit heavy and proving to be a slow read. The upside, I am learning lots about brain activity.

Random Bits:

1. I want to acknowledge a conversation I had a couple of weeks ago about authority vs. influence. His premise was that authority doesn’t exist. Authority alone is not enough to lead and that even in a position of leadership influence will still rule the day. I agree.

2. Regarding personas, I continue to see them not being used. You will lose the battle without them. Also try your best to ignore this post, except for the comments.

3. Regarding vision, I continue to see either no vision or poorly defined visions. You will lose the battle without a vision, largely because it is the key component to strategy. No vision, no strategy. Here is a good blog on product visions.

4. The price of your product is determined by the value it provides, not the cost.

5. Please visit my list of product management events. It is the most comprehensive list of events targeted towards product managers anywhere.

If you enjoyed this post, please leave a comment or subscribe to the feed to receive future updates. You can also follow me on Twitter. Tell other people about this post.

Roadmap Discussions

Stewart Rogers — Wed, 07 Oct 2009 13:39:51 +0000

Seems to be a hot topic this week, there has been many discussions about strategy and roadmaps. Is it roadmap update season already? Steve Johnson said: “Roadmaps are evidence of strategy. Not a list of features.” OnPM said: “re:Roadmap: R a hi-level plan based on what is known today. May include strategy (good or bad) but may not.” OnPM also offered up a couple posts to read: What’s the deal with Product Roadmaps? and Agile/Scrum and Product Roadmaps. It seems from the discussions and comments that the general consensus is that if you open PowerPoint, plot out a timelines and insert features into the timeline, you might have what is considered by some as roadmap, but not a strategy. It also seems that most agree that your roadmap is your strategy. So what is missing? What information do you need in your roadmap to make it a strategy?

If you enjoyed this post, please leave a comment or subscribe to the feed to receive future updates. You can also follow me on Twitter. Tell other people about this post.

Authority vs. Influence

Stewart Rogers — Thu, 24 Sep 2009 15:15:14 +0000

Leadership is a frequent topic of discussion within the product management community. You won’t find much of a debate on the topic of whether product management is a leadership position, but you will find much discussion on the depth of the leadership. The discussion will span across whether product management should have people management responsibilities, whether they can be accountable for key performance indicators or just generally how to be a better leader.

In a recent webinar , David Locke suggested he though the product manager role was more accurately as titled as Product Leader. Perhaps David can comment as to why he thinks this title might be more accurate. He discusses this in the webinar around the 44 minute mark.

The product management leadership angst generally occurs when it appears like a lack of authority is blocking your plan. The reality is that your powers of influence are probably lacking.

If you know me (actually maybe no one knows this), I love word definitions. I look up one word a day, mostly due the fact that I had a history of not reading very much. I am reading much more now. Anyway, here is how the Merriam-Webster Online Dictionary defines authority and influence. Actually they have a few different definitions for each word (of course they do), but I thought these were closer aligned to product management than the others.

Authority 2a: power to influence or command thought, opinion, or behavior

Influence 4: the power or capacity of causing an effect in indirect or intangible ways

From a product management perspective, I typically get nervous if you are managing a product and people. The people distract from the time that the product requires and not managing people will generally preclude you from the authoritative leadership you might be seeking.

The power of influence is perhaps the most important tool in your professional toolkit. It should be a skill that you are constantly working to improve. It blends in a number of your personal traits including likability, compassion, empathy and understanding. But it also requires that you put the effort on your end to be able to justify anything you might need. People can be more easily led if you use market-, fact-or customer-based evidence for your requirements.

I tell people that product management is 90% leadership and of that 100% will be by influence and supported by all your market sensing activities.

“You can influence lives for a lifetime of success by contributing to the foundation for the journey.” — Ivy Meadors

Again, I defer you to the two experts on the topic of product management and leadership:

Image Source: Bonner Center for Service and Learning

If you enjoyed this post, please leave a comment or subscribe to the feed to receive future updates. You can also follow me on Twitter. Tell other people about this post.

Repost: Use Cases vs User Scenarios

Stewart Rogers — Mon, 21 Sep 2009 15:06:09 +0000

This is a repost of a post that I did on the Product Management View. There were some interesting comments on the original.

Finally, documented clarity around the difference between use cases and user scenarios.

Let me summarize the difference. A use case is a step-by-step account of system behaviour associated with one or more actors. A user scenario is concrete description of a very specific interaction, but one that is chosen to be typical or representative. OK, now what does that mean?

Use cases are very detailed and typically define the actors, a brief description, pre-conditions, the main flow (i.e. happy path) and any alternate flows, sub-flows and exception flows. It will also describe the state of the system at the end of each flow, happy or otherwise (i.e. post-condition).

User scenarios are slightly more creative. They are typically narrative versus the bulleted / numbered form of a use case. They incorporate individual user characteristics (i.e. a persona) while outlining the tasks undertaken to achieve goals. Essentially, you tell a short story about your persona interactiing with your product.

Product Managers will survey their external stakeholders, end users, customers and prospects to determine what the system will do and how it will be used. This is captured in the form of user scenarios, first informally, then expressed more formally in a use case model. At the end of the day, the differences are very minor but you can start to see how they are relevant and important to the software development process.

If you enjoyed this post, please leave a comment or subscribe to the feed to receive future updates. You can also follow me on Twitter. Tell other people about this post.

Responding to Change

Stewart Rogers — Tue, 15 Sep 2009 17:22:41 +0000

I swear I have written half a dozen posts in my head in the past week, either while driving or walking. I really need to learn to channel my inner Winston Churchill diction skills. Alas those ideas are lost for now.

Over the past month I have been mentally wrestling with change. Death, taxes and change are about the only things guaranteed. With respect to change, you can be guaranteed change will happen and will affect something.

Change can and will come from market conditions, sales, marketing, customers, executives, support, engineering and many more sources. Change can and will affect everything including revenue, cost, project plans, feasibility, roadmaps and many more.

As product mangers, every day you have to deal with change. Every day you have to deal with the effect of that change on your product. The successful product managers, the ones who cope with change the best, are the ones with a sound strategy that reduces the risk of change and/or enables them to respond to the change.

Image Source: Center for Educational Technologies

If you enjoyed this post, please leave a comment or subscribe to the feed to receive future updates. You can also follow me on Twitter. Tell other people about this post.

Strategy versus Tactic

Stewart Rogers — Mon, 07 Sep 2009 03:25:11 +0000

A lot of us live by the market-driven sword and after reading the following post: What is a “Market-Driven” Product?, I wondered, is ‘being market-driven’ a strategy or a tactic. My initial thought was that it couldn’t be a strategy because it is not really measurable. I suspected that as you tried to find a deeper meaning to why ‘being market-driven’ was labeled as a strategy you would find that it is not a strategy, but a means to a strategy. Therefore, it has to be a tactic if we base the criteria of strategy being the ‘what for’ and tactics being the ‘how’. How do we achieve our revenue targets? By being market-driven. Not so fast. Tactics are activities to achieve needed to achieve the objective – implement the strategy. Is ‘being market-driven’ really an activity? It feels a bit high-level and not really actionable. I posed the question, is ‘being market-driven’ a strategy or tactic, to the #prodmgmt community on twitter and one of the first responses (of many good responses) was from Adam Bullied who said it was a philosophy. Interesting. We know from other articles and experts that strategies are really in place to guide decisions. We also know that three of the main components of a strategy (or a set of strategies more likely) is the mission statement, vision statement and values. When Adam mentioned it was a philosophy, my immediate thought was ‘being market-driven’ is better defined as a mission statement. It seems like more of an overall goal that is accomplished (in this case, maybe never completed) over time as other (real) strategies are achieved. In the end, I believe that ‘being market-driven’ is more of guiding philosophy used to help shape strategies versus an actual strategy or tactic. It is a useful principle for us to put a decision-making framework in place, but not for making actual decisions. P.S. I found this – Strategy and Tactics By Eli Goldratt, Rami Goldratt, Eli Abramov – really interesting. This too – Strategic planning. Image Source: Austin Cotton Company

If you enjoyed this post, please leave a comment or subscribe to the feed to receive future updates. You can also follow me on Twitter. Tell other people about this post.

Repost: Searching: Product Management Architect

Stewart Rogers — Fri, 04 Sep 2009 11:46:34 +0000

This is a repost of a post that I did on the Product Management View. There were some interesting comments on the original.

Sorry, not a job posting… I am all theory here.

In times when people are reducing staff and cost cutting, it would seem odd that I am about to highlight another required role. I want to highlight an article to support a problem that I am seeing in medium to large sized organizations. From Pragmatic Marketing: Software Product Architect Job Description

As Product Architect, you will lead the design effort on a variety of projects in a highly collaborative, fast-paced environment. Your role is to design innovative solutions to real market problems. You will work closely with product and marketing managers, user interaction designers, and software engineers to develop new product offerings and improve existing ones. This position reports to the VP of Development.

Consider this situation… Two product managers who are based in different offices, organizationally on separate teams and each own one product. Both products are typically bundled and used at a customer site and except for the rare integration scenario neither product manager collaborates with the other. Imagine if you will, each Product Manager receives a separate enhancement request from a different customer asking for the same thing. Separately, they each run through basic sensing techniques to determine the pervasiveness of problem and articulate the problem statement for their product. Awesome! Now what?

They have documented a problem for their product that should potentially be solved in one and only one of products. The challenge at this point, how do they recognize that they are on the verge of writing requirements, getting estimates, passing it through various validation stages for the same problem, in essence duplicating effort? This becomes a bigger problem if the development team builds the solution twice.

In practice, we want one of the product managers to identify a problem, document it and the other product manager to identify a problem and recognize that the problem already exists. Technology can help, at least you will have a central repository for searching, but still required is discipline to collaborate, strong writing skills to ensure they are communicating in the same language and responsibility to do the right thing (make the right decision).

On the development side of the organization there is usually an architect type role that binds everything together, someone who is ultimately responsible that the technical designs are consistent and within the existing framework to ensure efficiency on the development side (no one is duplicating effort). I think the Product Management teams need this role too (or someone with this responsibility). I want to think of this as a Product Management Architect. This is someone who has overall responsibility for the quality of the problem statements, someone who is responsible for the best solution for those problem statements, someone who holds the big picture for the product portfolio and someone who has the potential customers in the front of their mind, not the technology.

The simplicity of my scenario doesn’t really do the problem justice but if you start to think about a 15 member product management team that parses maybe thousands of inputs into hundreds of problem statements how pervasive this problem can be.

At the end of the day, as technology providers, operation efficiency is paramount to our success and maybe even a differentiator. Duplicating effort is the opposite of efficiency. The market sensing and problem identification is the bread winner of product management and the key to efficiency begins at the point of problem statement concept.

Last point, for the smaller groups I’d like to see you begin to have problem statement regular (weekly) review sessions on a regular basis. No harm can be done by reviewing the problems experienced by your customers.

If you enjoyed this post, please leave a comment or subscribe to the feed to receive future updates. You can also follow me on Twitter. Tell other people about this post.

Book Review: Winning By Jack Welch, Suzy Welch

Stewart Rogers — Sun, 30 Aug 2009 22:12:27 +0000

I recently finished reading Winning. I was looking for something on leadership and poked Art Petty for a suggestion. Thanks Art, this was a classic read.

There were so many good lessons in here with respect to leadership and strategy it was almost overwhelming. One of my favourite topics was the chapter about candor; a truly powerful skill for the old mental toolset. Although I understand the power of this, I am aware of how this could be truly damaging to your career if not used properly.

can•dor (kndr) n. Frankness or sincerity of expression; openness.

Despite the book having leadership undertones throughout, there was a great chapter on leadership where Jack discussed eight things leaders do. This list includes team evaluation, coaching, articulating the vision, making decisions, probing and pushing with curiosity and inspiring risk taking.

lead•er•ship (lē-dər-ˌship n. The act or an instance of leading.

Lastly, he wrote a chapter on strategy. Given my interest in what strategy is and how people perceive, it was refreshing to see him try to simplify it. I loved this quote:

… strategy is actually very straightforward. You pick a general direction and implement like hell.

After reading that, there is no wonder the first chapter was all about mission and values. His definition of strategy is:

Strategy means making clear-cut choices about how to compete. You cannot be everything to everybody, no matter what the size of your business or how deep its pockets.

I cannot disagree with that.

He then broke down five questions to make your strategy real:

What the playing field looks like now?
What the competition has been up to?
What you’ve been up to?
What’s around the corner?
What’s your winning move?

I could go on with lessons learned from this book, but like Made to Stick I highly recommend that you read this book.

Image Source: HarperCollins Publishers

If you enjoyed this post, please leave a comment or subscribe to the feed to receive future updates. You can also follow me on Twitter. Tell other people about this post.

Repost: Book review: Tuned In

Stewart Rogers — Sun, 30 Aug 2009 21:14:00 +0000

This is a repost of a post that I did on the Product Management View.

Just finished the book, Tuned In (by Phil Myers, Craig Stull, and David Meerman Scott), and I must say. Well done! The book, by simply stating, outlines the following steps: find unresolved problems, understand buyer personas, quantify the impact, create breakthrough experiences, articulate powerful ideas, establish authentic connections to create a resonator. A resonator is the perfect solution to a specific problem. It is a product or service so powerful that it sells itself, an offering that connects to what your market values most and an idea people immediately understand has value to them. I grabbed this content from their blog, Get Tuned In which is a great resource as well. I like the emphasis on problem statements and the potential buyer. So much time is spent today by Product Management on the post-sales Buyer.

Tuned In is one of those books that you will be entertained by, amazed by, not be able to put down and be inspired to change the way you approach product management. Most importantly, you will want your Executives to read it.

Here are some other bits of wisdom from the crowd on Tuned In.

Buy the book here: Amazon, Chapters.ca

Image Source: Get Tuned In

If you enjoyed this post, please leave a comment or subscribe to the feed to receive future updates. You can also follow me on Twitter. Tell other people about this post.