Tag Archives: product teams

Don Vendetti on the State of Product Management and ProdBOK

Bringing Needed Definition to the Product Management Profession

Part of the ProdBOK© Series

Don, thanks for joining me today.

I know that you’re very active doing product management consulting in the Seattle area. What are your observations about the evolution of product management?

(Don Vendetti) Greg, thanks for the opportunity. I started my career on the engineering side (eons ago), and was fortunate to get into a company with a strong development process that included product managers who managed the entire product lifecycle, and with a high level of collaboration. What was odd to experience – as I moved on – was how narrowly defined the product management role was in other companies. It was frequently reduced to a support role for either Development or Sales, or both. Over time as I evolved to leading the product management function, I was getting hired into organizations to “fix” the department, as the function wasn’t doing what the organization needed or expected. This is also often the case for why I’m hired as a consultant.

The success of product management in any organization is highly dependent on three key foundations. First, the executive team needs to view the function as strategic and realize the importance of linking the company strategy to the product strategy. Without this driver, the product managers will inherently be relegated to a tactical function. Next, clear roles and responsibilities need to be defined for the how the team works with the rest of the organization. Other complementary functions also need to also be appropriately defined and staffed, such as project managers, technical sales support, and technical architecture or planning resources. Without them, the product manager will be forced to pick up the roles and get spread thin or there will be a large gap that’s addressed in an ad-hoc manner. Finally, the product managers themselves need to have a broad skill base, both strategic and tactical, to span all of the needed tasks.

Unfortunately, while there are bright spots here and there where all these elements are in place and product managers are really making a difference, the overall industry situation has lots of room for improvement.

As you look back on the last five years what do you think the most significant changes to the product management profession have been?

(Don Vendetti) One thing that is clear is the need for product management is as strong as it’s ever been, and is continually misunderstood as to the value it can provide. As far as changes go, the two biggest that I’ve seen are both in the software branch of the product management tree.

Agile is the first and has been a double-edged sword. On one hand, the role of product owner that many product managers perform has enabled them to engage more with the Development team on a regular basis. What I hear from Development managers is they finally feel like the product managers are adding value to their organization more than in the past. However, on the flip side, this has often resulted in less ability for the product managers to focus on the longer term product strategy and also ensure proper delivery of the product to the rest of the organization. I’ve seen this work the best when a product manager is partnered with a dedicated product owner who’s more of a requirements specialist, like a business analyst. This allows the day-to-day interaction with the Development team while also ensuring the more strategic and broader cross-functional activities are being effectively covered.

The second change is in the user experience (UX) and design side, and I’ve seen the responsibility increasingly moving from the Development team to the Product Management team. While this is a positive change in my view, since the user interface (UI) is such a major part of a software product, it has created the unfortunate situation that many product managers are doing UI design with no formal training and without the help of qualified UX professionals. There is clearly a shortage of UX professionals to go around, so product managers that find themselves in this position would benefit greatly with some formal training in UX, and it would absolutely raise their value to any software organization.

Do you think the new ProdBOK will help to address any of the challenges we have discussed so far? If so, how?

(Don Vendetti) I do believe the ProdBOK can help create awareness about the importance and the potential of the role, and how it can deliver higher value to a company than just short term tactical deliverables. If you’ve never been in an organization with a fully functioning product management group well aligned with the other functions, then you probably don’t even know what the possibilities could be.

In writing sections of the ProdBOK, I tried to clearly identify where and how the product manager creates the most value, while acknowledging that they often also have to wear many tactical hats. I’ve also tried to point out the areas where others need to take the lead in the process so that the product manager can stay focused on the market need/problem and delivery of the whole product across the organization.

At this point of the profession’s continuing evolution, getting a consistent view of the role is probably the number one opportunity for the ProdBOK to achieve, even if the role is customized in various ways to meet the unique needs of each company. And, of course, executives and other functional leaders need to be exposed to it to understand the opportunity available to them.

Don, why did you choose to participate in the development of ProdBOK?

(Don Vendetti) As part of my consulting practice, I’ve also done a fair amount of product management teaching in a university extension program, and through formal training courses within my consulting practice. This has given me the opportunity to look at the entire product management lifecycle process, and especially the upfront product strategy piece, while experimenting with different ways of implementing it. I also enjoy writing and have written several articles which are available on my website. The opportunity to help on the project seemed like something that leveraged my background and could have a bigger impact than I could make directly through consulting.

I also thought I could get it done in a few months. Hah! Here we are a year later finally getting this industry-wide collaborative effort to publication. The whole project was very much like creating a new product, including the twists and turns you have to make along the way as you encounter trade-offs.

Any final thoughts?

(Don Vendetti) Just a couple of last comments. First, I’m certain this is just the beginning of a journey for product management to establish a strong footing and I expect the ProdBOK to evolve significantly over time. This is a first attempt and there is plenty of room to expand it and fill in the blanks going forward as product management is a dynamic profession. Of course it helps to have someone like you driving the vision and deliverables, and I enjoyed working with you Greg.

Second, in some ways, contributing to this publication has helped me realize that I do miss being actively engaged in the development of products, as consulting usually only gets me limited playing time in a part of the game. So, moving forward, I’ll be heading back into the product world to be an active participant running a marketing and product management function and attempting to apply the concepts described in the ProdBOK.

Onward!

Editors Note: Thanks Don. On behalf of the ProdBOK editorial team I want to express our appreciation for your significant contributions to the effort. I also want to offer my personal thanks as you’re great to work with as well! I look forward to future collaborations and best of luck with your new position!

Greg Geracie is the author of Take Charge Product Management©, the Editor-in-Chief of The Guide to the Product Management and Marketing Body of Knowledge (ProdBOK), and the leader of this initiative. ProdBOK is an industry-wide effort to standardize the practice of product management sponsored by the Association of International Product Management and Marketing (AIPMM).

ProdBOK is a registered trademark of AIPMM.

Building a Bridge from the Current State to an Agile State

Leave a reply

The Chronicles of an Enterprise Agile Transformation (Part Four)

Blog Post by Steven Starke, Actuation Consulting

Achieving the Agile State

Finally, we got to the “heart” of the presentation where the engineering lead described how we were going to change our thinking from our current state development practices to our proposed new state of Agile development. The following diagram was presented as an overall high-level mapping of current state to the Agile state.

The Engineering team walked through each phase providing guidelines for each stage of development throughout the project life cycle. They went phase by phase, providing a bridge between the current product development methodology (waterfall/incremental) phase to the new Agile methodology phase.

Editorial Note: I took issue with this diagram because it didn’t call out the Project Manager role. There seemed to be some assumptions being made that a project manager was now equal to a scrum master. To read more about this debate check out my blog post on http://www.planbox.com/blog/.

Below are the guidelines by phase that were presented:

Requirements Phase to Release Planning Phase

Guidelines for the Release Planning phase:

Release duration should ideally be 3-4 months and no more than 6 months

Define your project team: Following roles should exist on all teams
1. Product owner, Scrum Master, Development Manager, Architect, Developers, BAs, QAs, Operations representative
Review project goals and minimal marketable features (MMF) needed for a viable release
Categorize high-level requirements into features
1. Break requirements into functional themes
2. Create technical themes (plumbing and architecture related) and operational readiness related themes. List specific efforts needed related to deployment, performance, administration, and monitoring of the application in production
3. Meet with Operations to incorporate their feedback
Conduct overall release sizing based on high-level requirements
1. Best and worst case estimate by themes with the team. If estimates are different from the original estimates that were provided in the investment planning process, then discuss the discrepancy with the product owner
2. Capture all assumptions being made during the sizing effort and review these assumptions with the entire project team

Analysis Phase to Technical Feasibility Phase

The Analysis phase in the current product development lifecycle would now be called Technical Feasibility. This new phase would consist of the following guidelines:

No more than 4 weeks long for a 4-6 month development project

Team to create stories for conducting technical feasibility at theme/feature level
Product owners to work on the detail requirements. This work can be captured as stories with design details in the story narrative OR in a separate document.
Team to review the detail requirements at theme level and brainstorm on the technical approach
Conduct Reveals with the product owners and the entire project team to review progress
Team to create technical approach document(s) by theme
1. The purpose is to document the decisions made by the developers and the architect
2. In lieu of detail technical specifications, we recommend, data and process flow diagrams, architecture diagrams (e.g. if a 3 tier architecture, components by tier, web services architecture etc)
Create product backlog for implementation
1. Stories by themes created by the product owner
2. Stories estimated by the team – A story should ideally be 3-5 days of effort
3. Team to create pre-requisite technical (plumbing/architecture) stories for the functional stories
Conversation with the product owner on total effort being spent by theme (and if it has an impact on the project schedule, revise the project schedule and get approval from stakeholders)
Revise the Release Plan

Iteration Zero – Get Ready for Development

This, Iteration Zero, was a brand new phase for the development lifecycle. The following were the guidelines:

Project created in source code repository
Foundational technical proof of concept provided (this could overlap with technical feasibility)
Test driven development and continuous build infrastructure in place
Check licenses of all Open Source software for compliance and verification of all 3^rd party software and versions to be used
Test strategy and planning
1. Setup environments
2. One of the environments should match in setup/configuration to production
3. Additional environments that might be needed: Operations testing, UAT, Automated regression testing

Iterative Development

The Development phase in the current product development methodology would now be explicitly called the Iterative Development phase. The guidelines for this phase are below:

Daily Scrum meetings and daily feedback to the team on progress with iteration burn down chart needs to occur.
Team iteration planning for the upcoming iterations should be occurring
Iteration tracking should be done by the Scrum Master
A “working” product delivered with every iteration. “Working” being defined as being able to be tested and integrated, but not yet pushed to production. It may take several completed features before a release is pushed into production.
Cross-functional team reveals need to occur to demonstrate new functionality
Team retrospectives must be conducted by the Scrum Master to discuss what went well and what needs improvement
It’s important for Agile teams to discuss operating mechanisms like the ones listed below. These are provided as examples only for guidance:
1. Encourage separation of environments to ensure the team truly has a working product every iteration e.g. Developers should not be performing demonstrations of code from their own workstation at the team reveals
2. BA/QA should acceptance test every story before its considered ‘done’
3. Developers should not have access to the acceptance test environment. Software should be deployed automatically and the software is required to work in any environment without the team configuring it manually.
In order for a story to be considered complete, it needs to work in an environment other than the developer’s workstation.
Story should only count towards the velocity of the iteration if the story passes BA/QA acceptance test i.e. meets the ‘Done’ criteria
Code complete at the end of development cycle.
Product defects should be handled in the following manner:
1. Defects should be part of backlog grooming
2. Defect triage with the product owner needs to occur in order to prioritize defects
  1. Critical – handle right away, take priority over story
  2. High – schedule in the upcoming iteration
  3. Normal – schedule with product owner’s feedback
3. Defect iterations should be scheduled in order to catch-up on defects if defect backlog gets too big

…At this point during the presentation, time ran out. We would have to meet again to discuss the feedback from senior leadership and what the planned next steps needed to be to continue the transformation.

Who Owns The Product?

1 Reply

Are product managers solely responsible for the product?

Who Stays with the Product Post Project Completion?

Part of the Product Management Facts Series

Few people would likely dispute that a product owner or product manager “own” the product in most organizations.

What do I mean by own? I mean having responsibility for optimizing the value of the product throughout all of it’s phases(from conception to ultimate retirement).

Of course, few things are ever black and white. In most instances my statement holds up to the 80/20 rule. Exceptions to this rule normally exist in early stage companies where the CEO or perhaps an engineer are calling the shots out of necessity. As the company scales, product managers are put in charge of managing the product and optimizing the value that’s created.

Assuming we’re in general agreement on the evolution of the product management function and that product managers own the product it’s interesting to drill a little deeper. In a recent survey we asked the question “what core product team members stay with the product after a product development project has been completed?“ Possible options included; project managers, program managers, engineers, user design professionals, product marketers, business analysts, brand managers, and so on.

If you had to choose from this list, which of these roles would you pick to stay on beyond a discreet product development project and throughout the various phases of the product life cycle? Any of the above?

Approximately 50% of survey respondents indicated that the product manager and product owner were the only parties to stay with the product post project completion. Engineers came in third place at 12% and all other core team member roles were in single digits!

While this makes intuitive sense, it also points to an alarming risk. A lot of critical product knowledge is being concentrated in one role. Given the exceptional risk, organizations need to give more thought to how to effectively mitigate an unexpected loss.

When was the last time your organization had a product manager leave and in doing so provide a well documented transfer of knowledge? It happens less than it should…

Here’s the actual data…

What Does Agile Mean to Organization’s Today?

Collaboration Leads to Improved Outcomes

The project manager / product manager relationship

Sure we know that effective collaboration leads to improved outcomes and more effective teamwork. But what specific functional collaborations are key in triggering creativity, problem solving, fostering further team communication, and ultimately improving project outcomes? Just putting everyone together in a room at project inception doesn’t necessarily guarantee success.

From my experience, the most successful product development projects were those that had the product manager and project manger tightly coupled from the very beginning. Spending more time developing this relationship from the onset will pay dividends and increase the likelihood of project success.

If we can agree that the goal of a product development project is to create, develop, and deliver a product to the market, maximizing its value – the customer benefit and experience – while ensuring the return on investment (ROI). Then, nothing ensures maximizing ROI more than getting the definition correct at the onset of a project. Knowing where you’re going and how to get there, at the beginning of the life cycle, eliminates waste by avoiding unnecessary course corrections throughout a project.

Leveraging the expertise of project managers at the earliest phases of a project helps to get this definition correct by bringing their best practices and lessons learned to the table at a critical juncture – the start of the project. Engaging project managers early has additional benefits: (1) Project ownership is now ingrained into its leaders because they have helped shape the execution approach; (2) By working together to form the overall project definition in the beginning of its life cycle, the foundation of a team dynamic is put in place that spills over into the rest of the project organization as it is put together.

Product managers and project managers can strengthen this relationship by understanding three fundamental concepts from the beginning of every project:

The product development and project life cycles are deeply intertwined
The product’s production process needs to be collaboratively defined with clarification of the major deliverables and resources required to get the job done
Shared incentives, performance objectives, and success criteria establish common ground for the entire team

Each one of these three concepts warrants its own discussion so I’m going to treat each one of these as separate blog postings. This should allow for more focused commentary allowing the concepts to be completely hashed out.