Category Archives: Product Management

Having moved from Austin, TX to Des Moines, IA to San Diego, CA, I have had to learn a few things about hiring product managers. In Austin, Product Management is a well-known profession and many talented people who are either natural product managers or trained ones are available for hire. Des Moines, like many areas in the country, is not a product management town. It is full of wonderful, hard working people but with industries centered around insurance and agriculture, there has not be high demand for product management, as a discipline. This is changing, both with the enthusiasm around Agile as a software development methodology and the increasing number of start-ups in the “Silicon Prairie.” The need for product managers is, therefore, on the rise. If you are tasked with hiring Product Managers, here are three tips to help.

Comfortable withOUT a job description

For nearly every job that I have had, I have lacked a job description. Not only am I comfortable with that, I actually prefer it. And I think most natural Product Managers feel the same. Of course, we all want to know the rough boundaries around our job but we tend to be very comfortable with ambiguity. A product manager’s job may range from strategic product visioning to market research to customer interviews to tactical prioritization to sales training to process documentation and much more. What you intend to get done when you arrive at the office may differ completely from your accomplishments at the end of the day. As one of my colleagues so eloquently stated, “A product manager is the CEO of that product” and just like company CEOs, you have to roll with the punches and respond to the needs that are presented that day.

The fact that I can title this blog “Lessons from an Author” is both amazing and surreal. You see, my first book was just published so I guess I can officially say that I am an author. (Buy it here!) Holding the book in my hands led me to reflect on the last 18 months and the journey that my co-author, Sondra Ashmore, and I have been on. For what they are worth, here are the lessons that I have learned along the way.

Persistence Required

When writing a book, or doing any meaningful and challenging undertaking, you must have persistence. This is obvious, I know, but let me share the backstory. There were two chapter in our Agile textbook that were particularly difficult – the chapter on roles and the one on culture. Not that we didn’t have plenty of content, that was never the problem. It was trying to figure out a way to convey the information in a logical and cohesive fashion. Each chapter was re-written nearly from scratch three times. By the time you are writing a chapter for the third time, it is easy to get frustrated, depressed, aggravated, annoyed (can you tell that the memories are still fresh??) and a whole host of other emotions. This is when you need someone to pull you back to the surface. In my case, I was lucky to have Sondra. In my time of doubt, Sondra reminded me that this is the time and circumstances that separates published authors from those with unpublished work sitting in a drawer. It is persistence. Pure and simple. There are lots of great writers out there. But persistence is the distinguishing trait for true authors.

For the final blog post in our series about our upcoming book, Introduction to Agile Methods, we are going tackle the cultural impacts of an Agile implementation. Agile is a simple set of concepts to understand (once you read the book, of course) but that doesn’t mean it is easy to implement. It can be challenging for organizations to adopt principles like self-organizing teams, continuous improvement and frequent delivery. This chapter examines creating an Agile culture from the perspectives of a team member, manager and an executive.

Learning Objectives

Understand organizational culture and why it matters in an Agile implementation

Dive into ways things might be different in an Agile organization from a developer, manager, and executive viewpoint

Look at successes and failures in behaviors to see the cultural impacts

Understand how the Agile principles drive different behaviors in an organization

Explore how an Agile workplace differs for managers and the ways that they must change with regard to teamwork, trust, and transparency

Review the role of executives and how their behavior can position an Agile transformation for success with executive alignment, respecting priorities, creating supportive environments for the teams, and driving the right behaviors with metrics

There is so much great content in this chapter, it is hard to pick one excerpt to spotlight. We chose the executive viewpoint and how important it is for the executive sponsor to embrace the change and provide consistent leadership.

Staying the Course

An Agile transformation is challenging for most organizations. Some command and control managers will fight the change, offering dire predictions of failed projects as examples of why this is a bad idea. Developers may not embrace the increased accountability and transparency, and some may choose to leave the organization. There are new expenses in the form of seating arrangements, training, and Agile tools that may stress the budget. Agile transformations also have a history of bringing chronic issues that the organization has ignored for years to the surface where they must be confronted. All of these are reasons why an executive might abandon the effort and simply revert to what is comfortable (but ineffective). Any change worth making is going to require effort, and Agile is no different. The strong Agile executive will work through these issues without wavering on the commitment to Agile.

Our Agile textbook is just weeks away from being a real, tangible thing and it is so exciting. Continuing with our blog series with excerpts from the book, this one comes from the final chapter titled Agile Beyond IT. One might wonder why an Agile textbook would dedicate a whole chapter to marketing products developed by Agile teams or even how Agile has been deployed in Marketing and other corporate departments. My co-author, Sondra Ashmore and I believe that it is important to remember that a product is not successful because it was created by an Agile team. Successful products have to be launched correctly too and that can be an equally significant challenge. Here are the learning objectives from this chapter as well as an excerpt on marketing with agility.

Learning Objectives

Learn how the Agile values apply to bringing products to market, beyond the development efforts

Understand ways to systematically collaborate with the marketplace through discovery and validation

Explore the changing dynamics for marketing of products with the proliferation of new channels and the complexities of brand management with social media

Review how wireframes and prototypes can be used in the marketplace to inform priorities for Agile software development teams

Learn how to be Agile when launching products by managing features, limiting the initial audience, and pursuing continuous enhancements

Take the Agile concepts beyond IT and product development and see how other corporate organizations can benefit from Agile values and principles

Discover how Marketing has taken Agile to a whole new level of discipline by creating their own manifesto

Marketing with Agility

There are a number of ways to effectively market products built with Agile development teams. Some Agile purists are uncomfortable committing dates and features to the marketplace, but in most industries, it is not optional: Existing customers and late-stage prospects demand to know when and how the product will evolve. We outline several ways to balance these two sides.

One of the amazing things about co-authoring this Agile textbook (Introduction to Agile Methods) with Sondra Ashmore has been the opportunity to learn new things and research other methodologies. For our excerpt from Chapter 8, Tracking and Reporting, I had the opportunity to research Feature Driven Development (FDD) and a great concept called Parking Lots. Here are the Learning Objectives for this chapter and more on FDD Parking Lots.

Learning Objectives

Understand Kanban, its effectiveness, and when it is used

Learn the definition of work in progress (WIP) limits and how they can identify bottlenecks in processes

Explore different tracking mechanisms used in XP, Scrum, Lean, DSDM, and Crystal

Understand burn charts, both burn-up for release management and burn-down for sprint tracking

Examine feature-driven development (FDD) parking lots and how they assist in tracking large and complex projects

Learn the different strategies for tracking quality through an iteration

Understand the importance of meetings in tracking progress and course correcting

Learn the purpose and desired outcome for each meeting—the daily stand-up, the Sprint review, and the retrospective

Consider the metrics for measuring the success of Agile projects

Feature-Driven Development (FDD) Parking Lots

FDD incorporates an excellent way to track progress on larger projects where many activities are contributing to a cohesive whole. For our Cayman Design project, we want to create and sell weather-related calendars to customers; this is a large departure from the other features in our weather app because we have to consider inventory, shipping, and payment details. An example of an FDD parking lot might look like what is shown in Figure 8.7.

This tells us that the feature “Collect Customer Information” consists of seven stories totaling 32 points. At this moment, we are 75% complete, and the feature is needed by August 2014. The color on the story can indicate its health, this particular story being yellow, meaning it is in jeopardy. Although this is an interesting depiction of information, it is not necessarily more valuable than any of the other Agile tools we have discussed—that is, until you add many other components, and then the picture painted by the FDD parking lot is incredibly useful (see Figure 8.8).

In the next edition of this blog series highlighting excerpts from our upcoming book, we will tackle the tricky subject of Technical Debt. To be honest, I had a hard time choosing a single topic from this chapter because there are so many great topics covered – Definition of Done, Planning Poker, Value Stream Mapping, the Kano Model, Velocity, the XP Planning Game – and much more in this chapter on Grooming and Planning. And it includes an interview with none other than Mike Cohn! If this post, or any of the previous ones on Roles or Requirements or our guest blog from co-author Sondra Ashmore inspire you to want to purchase the book, please visit Amazon and search on Introduction to Agile Methods.

Back to Planning and Grooming, here are the Learning Objectives for the chapter.

Learning Objectives

Understand the elements of a product backlog and what traits lead to the strongest deliverables

Dive into prioritization and learn different methods for understanding what is the most important feature or item to work on

Explore estimation and the different practices and measures that are used today

Understand story points and planning poker as ways to discern the level of effort and complexity of the user stories/requirements

Learn the other inputs that affect the planning process, such as team velocity, definition of “done,” technical debt, and bugs/defects

Evaluate Sprint planning and the XP planning game to learn how commitments are made and work is planned

See how maintenance work can be incorporated into Agile teams

Review the triple constraints model and how it is handled within the Agile framework

We are getting closer to the publication of the Agile textbook that I have co-authored with Sondra Ashmore. It is such an exciting time for us and I want to use this blog series to highlight chapters from the book. I hope you enjoy this so much that you want to order the book. Pre-orders are available on Amazon right now – just search Introduction to Agile Methods by Sondra Ashmore and Kristin Runyan.

One of the chapters that I was responsible for addresses the roles within Agile and specifically Scrum teams. Here are the chapter learning objectives as well as an excerpt from the section about Product Owners, something I am very passionate about.

Learning Objectives

Understand the roles in Scrum with their specific responsibilities—product owner, Scrum master, and team

Identify the attributes and personality types that are most successful in the various roles

Learn the Agile definitions of “chickens” and “pigs”

See how extended team members interact with the team

Compare and contrast the roles in Scrum and the other methodologies

Walk through practical examples of how the roles are filled in different-sized organizations

Product Ownership – Breadth

Another nuance of the product owner role is the breadth of his or her ownership. Does one product owner manage multiple products? Or is one product so big that it requires multiple product owners? Both of these situations are common in the workplace where teams are thin and expectations are high.

To examine the first instance, what are the advantages and disadvantages of having one product owner responsible for multiple products? The biggest risk factor is time and attention. Can the product owner devote adequate time to every product that he or she is responsible for? Does this person have the necessary depth of understanding to truly collaborate with IT on the best solutions? It is a risk, but certainly one that can be overcome.

In the instance where the product is large enough to have multiple product owners, there is a chance that the priorities will not align. Related to the previous reference of business value, if one product owner wants to expand to new cities to attract new users but another product owner places top priority on improving the processing speed, then you can run into conflicts. However, one of the core tenets of Agile is collaboration, which includes collaboration between product owners. Product owners need to be in communication with each other to clearly articulate the best plan for all groups—knowing that at any given time, one group’s needs will take precedence over another’s.

Even if you have a single product owner for every product, that does not mean that things are easy. Between systems there are interactions, and to create a new feature or make a modification, the product owner may need to consider dependencies.

Product Owners – like great products – must be developed. While some skills are innate, others must be learned and organizations tend to throw new Product Owners into the mix without adequate information. In this blog series, we have explored new product owners who are assigned to new products and those owning a system migration. Now we are going to explore a new product owner who takes over an existing product with a robust product backlog. In some respects, one might think this is the easiest of the three scenarios but it comes with its own set of challenges. Here are some tips for how to get started.

1. Get to know your customers

The first step to get your arms around an existing backlog is to understand your current customers. To do this, you need both

Backlog in Jira Agile

qualitative and quantitative information. Data is always your friend. How many customers do you have? Are they profitable? Are they the ideal customers that you want to attract? Once you understand the numbers, now you need to actually talk to customers. Schedule interviews with key customers – both happy ones and those that are frustrated. Use your strong product management skills by asking open ended questions. My favorite is “What keeps you up at night?” Let your customers talk or complaint or suggest – wherever the conversation goes can be valuable. Knowing who is buying your product is very important.

We have a problem with Product Owners in Agile. These are incredibly difficult jobs and it is easy to blame the product owner when things go wrong because “the requirements were not clearly articulated or prioritized.” That might be an easy path, but it often is neither correct nor fair. Instead of pointing fingers, let’s support our Product Owner and give them the training and tools that they need to be successful. Just like we introduced with developing New Products and explored with existing backlogs, here are some tips and tricks to managing system migrations.

Image Source: http://tinyurl.com/nghasux

Moving from old technology to new is a common project for Agile teams. Many companies have platforms that are no longer providing the necessary value and features to the marketplace and IT organizations are faced with the challenge of moving from an old, tired, inflexible system to a new, dynamic, configurable system. Or it might not be that dramatic – perhaps you just need to move from one software package to another for cost or vendor relationship reasons. Either way, a new product owner must discover how to break this big effort down into manageable chunks. How do you get started?

1. Analyze what is being used

The first step is to figure out what pieces of the legacy software are actually being used. There is no sense migrating functions or features that no longer matter to the organization. If you can weed out some portions of the migration to minimize the size of the effort, that is great news for the company. Some firms want to skip this analysis step and just build “like for like.” This approach will save time as part of the project prep, but it will cost precious developer time down the road.

Many of the complaints that I hear often about Agile implementations concern the product owner. Either the business is not engaged appropriately, or the product owner is indecisive or unavailable, or the quality of the requirements/user stories is poor. Whatever the situation, the product owner is often “at fault.”

Instead of lamenting why we do not have good product owners, I would like to shift our thinking to: How can we build a Product Owner? These are challenging jobs and often the people put in them have little background on what is expected of them. This is the first in a series of three blogs to help us build better product owners, which will lead to better products. First, let’s examine a new product offering. Where would a new product owner start?

For this effort, I recommend a three step process and I have to give credit to David Hussman who provided some of the inspiration for this topic.

1. Create personas

Who is going to use this new product? Who is your buyer? Will you have power users and casual users? Do you need to consider administrative users?

Personas first came into the conversation with Alan Cooper’s book “The Inmates are Running the Asylum” in 1999. Personas are fictitious people who are going to use the system so the Product Owner can think about user interactions and how best to optimize the experience. Let’s map out a few personas.