Tag Archives: product team

Cindy F. Solomon of Global Product Management Talk on Product Marketing in Silicon Valley

The View From Silicon Valley

Cindy, welcome to Take Charge Product Management©.

As you look across the product marketing profession what do you see?

(Cindy Solomon) I see that what may have previously fallen under the umbrella of the product marketing function, is gaining attention in the blogosphere with sexier names, such as Agile marketing, growth hacking, or customer experience management. These may be new approaches, but they are grounded in the product marketing managment function to increase current product ROI, identify opportunities for new product iterations, manage the value proposition via positioning of the product, and create the business case for remaining competitive in the current market conditions and future trends.

Product marketing management has always been charged with concerns about how to squeeze additional value out of products already in the market, align the goals of the product with the business case KPIs, translate the value of the company brand into every experience, extract information from non-customers, identify patterns from data collected across various inputs, increase efficiency across the entire product management lifecycle, attach ROI to every program attached to the product in the marketplace, streamline sales and marketing procedures, facilitate new partnership, co-marketing, and strategic channel opportunities, track the market opportunities, threats and trends, and make the case for new products and innovation.

Given your unique perspectives, how do you think the ProdBOK Guide will help address the challenges of being a product management or product marketing management professional?

(Cindy Solomon) Having a product management body of knowledge will clarify the skills, knowledge, language and perspective for the product management professional. The ProdBOK will provide an orientation for people being thrown into product management roles without any foundation and open the door to understanding all of the elements that comprise the knowledge necessary, the procedures available, and how to identify appropriate tools to apply at various points in the product management lifecycle.

For those seeking product management positions, and for those identifying product management functions within their companies, it will define the requirements, orientation and basic foundation which is desperately sought after by individual product management professionals, product teams, decision makers, HR departments, and organizations of all sizes seeking to increase market share and product success.

The ProdBOK seven phase product lifecycle framework provides the visual representation to enable conversations across functions for everyone in the organization to be on the same page to identify what needs to happen based on the maturity of the product externally in the marketplace and internally within the organization culture.

(This concludes the first part of our two part interview with Cindy. More on product marketing management next week…To learn more about Cindy or to listen to Global Product Management Talk’s weekly broadcast click here.)

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

The ProdBOK mark is a registered trademark of AIPMM.

The Danger of Wearing Multiple Hats (on Product Development Teams)

1 Reply

Product Team Members are Juggling Multiple Roles

Part of the Product Management Facts Series

In the recent Study of Product Team Performance©, 2012 we asked survey respondents what role they played in their organization. We then asked if they were playing multiple roles on the product team.

The actual question was “If you play multiple roles, which best describes your secondary role?”

We asked this question because, as the recession took hold, we were seeing an increased number of organizations expecting their product team members, product managers included, to cover more ground. Ground that had traditionally belonged to other functions.

Here’s what respondents told us they were doing in addition to their primary role…

23% said project management
19% indicated business analysis
14% were doing program management
11% were assuming product owner activities
10% were doing some product management activities

We also learned that product team members are being asked to do more because their organizations had trimmed headcounts but not company ambitions. Said another way, while the number of FTEs had decreased the company’s business objectives did not reflect the reduced level of resources. As one survey respondent noted it’s a time of “lean resources, and grand ambitions.”

The problems associated with asking team members to wear multiple hats are numerous. They range from conflict of interest to diluted effectiveness. For example, asking a product manager to take on the project management role is a conflict of interest. The product managers job is to create value throughout the entire product management life cycle while the project manager is trained to keep a project within a well-defined boundary of scope, schedule, and cost. What happens when the optimal value falls outside of these boundaries?

Additionally, keeping with the product and project management example, assuming that product managers will make good project managers and vice versa is a dangerous assumption. Both of these roles demand singular focus and specialized training. A product manager does not just wake up one day and know how to effectively put into place a work breakdown structure. Nor is it feasible for a project manager to know how to craft a compelling multiyear product strategy. These are skills honed with time and training.

While I have focused in on product and project management the same can be said for the other co-mingled responsibilities identified in our survey.

The recession may have made combining these jobs necessary but it’s dangerous to assume that these roles can be intertwined indefinitely. Nor is it likely to be in the best interests of the organization. People tend to gravitate to what they do best. If product management is a team members passion, and project management has been forced upon them out of necessity, how much energy are employees truly giving to a role they don’t enjoy and have not been trained to do?

Juggling multiple roles is not a long-term solution. It’s only a matter of time till one or the other hits the ground. You can bet it will be the one that a team member had foisted upon them.

The Three Factors That Have the Greatest Impact on a Product Development Initiatives Success or Failure

1 Reply

From the Study of Product Team Performance, 2012 Actuation Consulting. All rights reserved.

Three Factors that Impact Product Team Success or Failure

Part of the Product Management Facts Series

If you were asked “What single action do you believe increases the likelihood of success in your product development initiatives” how would you respond?

We asked 1150 survey participants this very question and here’s what they told us.

#3 Upfront Planning - Respondents told us that upfront planning is critical to the success of their product development efforts but it’s being compromised given the current environment of constrained resources and leaderships fast changing priorities. It was pretty clear from the volume of responses that teams are unhappy about the lack of forethought currently being given to the planning process.

#2 Open Communication – Respondents clearly valued open communication within the team and across the organization. In fact, survey respondents overall opinion regarding communication was summed up nicely by the following individual. We “need to have open and honest conversations so that realistic expectations are set.” In other words, while communication is highly valued and deemed critical to the success or failure of product development initiatives it’s not as commonly practiced as it should be.

#1 Accurate Customer Needs Identification – Survey respondents indicate that time needs to be invested upfront to ensure that the team has clarity on customer needs. One respondent said that “gaining an in-depth understanding of the market and developing to a well-defined target” was the single most important thing the product development team can do to ensure success.

Interestingly, two of the three are front-end activities (planning and needs identification). The data from the study also indicates that these very activities are the ones that get compromised as under-resourced teams are pushed to go wide and compromise depth.

So the question is, if these are the most important factors that point to the success or failure of your product development initiatives – how long can teams go without the ability to go deep and invest time in planning and clearly identifying customer needs?

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.

From Old to New – The Chronicles of an Enterprise Agile Transformation

Leave a reply

Part Three: Setting the Stage

We left off with the engineering function tasked with further describing the transformation that needed to occur from the current state, waterfall / iterative to Agile. This presentation was given to the cross-functional leadership team and consisted of the following agenda items:

Review progress-to-date on the Agile initiative
Review proposals for the next level of rollout activities
Have a dialogue among the product leaders on the call, regarding other next steps or approaches towards an effective rollout
Receive guidance on the go-forward approaches.

The presentation kicked off by describing the essential elements required for a successful rollout. Engineering took the approach of presenting the material in a roadmap type of format (figure below) – stating, here is what we need to do and the timeline we need to do it in.

The bottom line was that we were going to be in a position to execute on the rollout plans by the end of the year (roughly 1 quarter or so to get everything in place). No one really questioned the timeline or the perceived aggressiveness of it. The initial feedback from leadership at this point was…”great, but show me the detail that supports this rollout”.

Next, a more detailed description of “where we are” was given to communicate all the work that had already been accomplished to date. Part of this description showed a maturity analysis across all the product teams. The analysis was conducted through a survey/questionnaire styled approach, allowing the teams to capture how proficient they thought they were with Agile development.

Overall, the analysis showed that coaching seemed to be working relative to teams that had not undergone any coaching type help. A product team paired with a coach achieved a greater understanding of how to execute through Agile then a team that didn’t.

Leadership seemed to understand the point that they were going to have to continue to invest in coaching if this Agile transformation was going to work. However, they needed more details around exactly what this transition was going to look like, to truly understand the cost…

We’ll discuss executive management’s other input in my next post (in two weeks)…

Agile Dominance – Fact or Fiction?

2 Replies

Product Management and Product Development Facts

Is Agile Truly Dominant? What are the Facts?

Part of the Product Management Facts Series

Across the entirety of the product management community it often seems as if Agile (otherwise known as Iterative Incremental) methodologies command the product management airwaves. Heated debates take place not only in the product management community but also across related disciplines such as project management, business analysis, and engineering. However, actual facts about the prevalence of these product development methodologies are rarely cited and, are in fact, hard to come by.

Before we get into the facts I would like to go on record and say I’m product development methodology agnostic. I don’t favor one method over another. Why? Because I believe that each of the possible range of options has their unique pros and cons. The key to choosing the right methodology is heavily dependent upon the size, culture, and resources of the organization, what you’re trying to achieve, the degree of risk involved with the project, and a range of other factors.

In fact, it’s quite telling that most product managers aren’t actively involved in selecting the methodology used to develop their products and create value! Frequently our partners in engineering make this decision for us. Their desire to do this is not to circumvent us but because they feel that they have a better grasp of these methodologies than we do.

To be fair they’re often correct. How many product managers do you know that can cite the pros and cons of the various iterative incremental approaches and contrast these to serial (Waterfall) processes? Our lack of understanding of these product development methodologies enable these decisions to be made for us. To a certain extent we have only ourselves to blame!

But I digress. So let’s circle back to the topic at hand.

Imagine for a moment we’re in a classroom with 100 product managers. If I asked the class how many of the people in the room were using “pure” Agile (meaning only Agile methods without blending Waterfall and Agile for instance) how many hands do you think would be raised? The majority I bet. At least that is what industry marketing volume would lead you to believe.

However, the facts appear to show a different story. We recently conducted a global study of product team performance and one of the questions we asked was “what methods do you use to produce your product?” The data showed that only 12% of the 607 global respondents indicated that they used “pure” Agile methodologies to develop their products!

The majority of these organizations were under $50 million in annual revenue and as the size of company grew these numbers tailed off. In fact, and this may be a shock, “pure” Waterfall is actually more common than “pure” Agile! The term Waterfall is often perceived as “old school” and people are hesitant to even admit that they use this methodology. But our data clearly shows that 18% of organizations are “pure” Waterfall! 6% more than “pure” Agile.

Both Agile and Waterfall methodologies were completely trumped by Blended methodologies which won hands down. Blended methodologies combine both Agile and Waterfall techniques to achieve a desired organizational objective. So while the world of product development has been changed by the introduction (or some might say reintroduction) of Agile the facts indicate that the debate about Agile versus Waterfall misses the point.

The real question is not which is better but how to optimize the combination of both methodologies!

The Science of Project Management: 4 Tips to Success

Leave a reply

The Science of Project Management is More Than Checklists,Tools, or Templates

Why do we think that what worked on our last project will work on our current one?

If the definition of a project revolves around it being unique, why do we try to standardize our approach so much? Checklists, templates, a PMO mantra of “this is how you should do project management” isn’t necessarily well received, especially during the early stages of product development.

Think about it – we approach a project with a bunch of standardized, project management lingo, asking a bunch of questions and it’s no wonder that, out of all the stages of product development, Conceive is where we find the role of the project manager the most underutilized. It’s as if our friends in product management want nothing to do with us. And because there is so much unknown during Conceive, we can quickly fall into the trap of thinking they’re right – there’s not a lot for us to do here – and be resigned to waiting until requirements are further along.

Product managers, on the other hand, often view themselves as solely responsible for figuring out all the answers during Conceive. This perspective can lead to a lot of unnecessary pressure.

Having project managers asking a lot of questions can be viewed by the product manager as challenging their capabilities, authority, or performance. We, project managers, often have a long list of questions. “So how are you going to go about figuring it out? What steps are you going to take? How long is it going to take you? Are you dependent on anyone or anything else to complete your tasks?” These are the typical questions we would probably start to ask – right?

In our mind completely harmless; in their minds, somewhat challenging. Product managers can become defensive and respond with statements like “there’s lots going on here!” Trying to figure early stage product development activities out isn’t necessarily a task by task process. Innovation isn’t something that can simply be put into MS Project. We’re going to be involved with market research and customer surveys figuring out our strategy for where we’re taking this product. A lot is going to change and be in flux over the course of this stage. Managing a task by task schedule won’t make sense.

So what do we do? How can we help, if no one is willing to talk to us? Perhaps it’s time to change our approach.

My background is in science. I was raised as a scientist long before I ever became a project manager. So, my perspective of the Conceive stage of product development is a bit different. To me, Conceive looks like this:

Formulate hypothesis
Test hypothesis
Record data
Evaluate hypothesis
Repeat

Those of you scientists out there might find this approach resembling the Scientific Method. The scientific method refers to a body of techniques for investigating phenomena, acquiring new knowledge, or correcting and integrating previous knowledge. To be termed scientific, a method of inquiry must be based on gathering empirical and measurable evidence subject to specific principles of reasoning. The Oxford English Dictionary says that the scientific method is “a method or procedure consisting in systematic observation, measurement, and experiment, and the formulation, testing, and modification of hypotheses.” The chief characteristic which distinguishes a scientific method from other methods of acquiring knowledge is that scientists seek to let reality speak for itself, and contradict their theories when those theories are incorrect.

Doesn’t this sound a lot like the Conceive stage of product development? We, as a product team, are trying to understand a perceived problem for which there is no identified solution. Customers may be telling us one thing, but their behavior may be showing us another. Markets need to be explored and data must be collected to either confirm or deny assumptions. All of this data must be validated before any true business case for the product (or project) can be developed.

Here are four tips that I use with product managers as I try to help them understand and plan their approach to Conceive:

Use your experience: consider the problem and try to make sense of it.
Form a conjecture: When nothing else is yet known, try to state the explanation, to someone else.
Deduce a prediction from the explanation. If you assume #2 is true, what consequences follow?
Test: Look for the opposite of each consequence in order to disprove #2. Is it a logical error to seek #3 directly as proof of #2.

This approach takes the technical project management jargon out of the conversation and centers the conversation around the importance of what the product manager is trying to accomplish. You have to remember, most people, although familiar with the profession of project management, really don’t understand the language, nor should they have to.

Remember, your goal as a project manager during this early stage is to provide your team a foundation – a foundation built upon clear performance objectives and success criteria centered on targets and measurement. Using the scientific method gives you a collaborative approach to achieve this goal.

Four Ways Executives Align Product Teams

Leave a reply

Part of the Product Management Facts Series

Earlier this year we conducted research into the dynamics of product team performance. As part of this research we asked a question about the mechanisms being used by executives to drive alignment across the core product team.

For the purposes of the study we defined “core team” as being composed of product, project, and program managers, business analysts, product owners, brand managers, engineers, and product design professionals.

The question we posed was “In which of the following ways does your organization support aligning members of a core product team?” Global respondents were offered five choices.

Strong executive support for the core product team
Shared organizational goals and objectives linking the team
Bonus compensation linked among core product team members
Product production process mapped so that all the team members understand their role and handoffs
None of the above

Based upon the responses there are three mechanisms that are commonly used to achieve alignment and one that is used less frequently.

Methods executives use to drive product team alignment

The most common response (31%) was shared organizational goals and objectives linking the team. In other words, a reliance upon the good will generated by shared goals and objectives that reach across the respective functions in order to drive improved alignment. In actuality though, we often see mixed results using this mechanism as the primary driver of alignment.

While this mechanism can work, it can also be trumped by the “functional” goals and objectives of the department an individual reports in to. In essence, individuals often choose between which of these goals are more important – the functional or the cross-functional – based upon their perspective of which is most important.

The second most frequent response was strong executive support for the core product team at 25%. Active executive engagement with the product team can be an effective way to ensure product team alignment. This mechanism can quickly surface resource issues, functional versus cross-functional conflicts, and a variety of other challenges that can undermine the teams alignment and ultimate success.

The third response was mapping the product production process so that all team members not only understand their role but the handoffs (20%). This is an effective way to ensure tactical alignment across the entire product team. Many organizations do not have a clear definition of product management’s role and responsibilities (we see it all the time!) and don’t take the necessary steps to map out how all the roles fit together. This is important as the product moves through the various production steps (from conception to ultimate retirement).

The fourth response is a controversial one. Approximately 6% of organizations report that they use bonus compensation stretching across all the various team members to drive performance. In other words, pay for performance linking the cross-functional team members to a common goal. The reason I mentioned that this is controversial is that opinions vary widely about the effectiveness of this approach.

The camp that is against the pay for performance approach commonly site a Harvard study that points out that this approach is ineffective. The pro camp states that putting “at risk” compensation at the center of alignment drives increased focus on the cross-functional goals as opposed to the natural bias of individuals to lean toward the functional goals (and the person they report into). In our experience we’ve seen bonus compensation work but it needs to be carefully thought out to ensure it’s an incentive and not a disincentive!

Finally, almost 18% of organizations report that they use none of these mechanisms to drive alignment! Presumably, this means that these organizations are operating solely based upon functional goals to the detriment of the team.

Creative Disruption – Never Lose Your Edge!

Leave a reply

Product manager, project manager, product team

Creative Disruption: A Tool to Enhance Product Team Performance

How do you keep your product and product team fresh and creative throughout the product development lifecycle? What differentiates those project managers who seem to have a successful team no matter what group of individuals they’re working with — versus those who seem to always have a dysfunctional team and troubled projects?

The answer to this question was never very clear to me early in my career. In my search for clarity, I read “Surfing the Edge of Chaos,” an article by Richard T. Pascale from the book Strategic Thinking for the Next Economy.[1] In his article, Pascale wrote about “complex adaptive systems,” which I translated into meaning “products.” He noted, “What makes a system complex and adaptive is the ability to anticipate and be proactive.” Said another way, human beings are complex and adaptive, and it’s our ability to anticipate and be proactive that allows us to survive.

Pascale helped me connect a project team’s ability to survive and be successful with its ability to anticipate change and be proactive. Pascale also wrote, “Stable equilibrium equals death.” For any system to survive, it must cultivate variety into its inner workings. If it fails to do so, it will fail to adapt to change successfully when it comes externally. While equilibrium endangers living systems, it often wears the disguise of an attribute. Species (people) are innately drawn toward stability and equilibrium – and the further they drift toward this destination, the less likely they’re to adapt successfully when change is necessary.”

We see this in products that have been on the market for several years. A once market leading product starts to show signs of aging, declining quality, and issues with customer retention. How do you cultivate a successful project team and prevent a once-functioning team from falling into the trap of complacency, unable to adapt to the new project?

The answer lies with something I like to call creative disruption. Creative disruption is the ability to periodically create a bit of disruption or change in the team to keep them fresh and functioning. It’s is a method to stop or disrupt the monotony of the everyday. Just because something worked for a team on a prior project doesn’t mean it will work on the next project. Keep the team on their toes and in a mode of constant, critical thinking. Your project results and team dynamics will dramatically improve as this technique prevents stagnation and complacency.

This change can be something as simple as co-locating team members or changing the development approach to the project. Implementing team change has got to be something that becomes natural and understood. Large, sweeping team changes rarely go well because the team isn’t used to and hasn’t recently experienced this type of change. The team has allowed itself to become stagnant, and big changes are perceived as completely disruptive. Small, steady streams of creative disruption in a project team can lead to better efficiency and productivity of its members and are better received than change introduced in a big-bang approach.

Creative disruption can also provide continuous improvement throughout the project. Often, project managers wait until conducting a lessons-learned exercise to identify opportunities for improvement, and then they don’t implement the lessons until the next project. By that time, the project is different, the team is different, and the lessons are old and may no longer apply.

Stop waiting and start addressing!

Continually evaluate the project and implement small changes to improve team efficiency and delivery during the project. Be creative if you have to. Creative disruption will have a very dramatic effect on building team bonds and furthering team integration as you strive to create that adaptive “ideal” team.

[1] Cusumano, M, A. and Markides, C. C. (Eds.) Strategic Thinking for the Next Economy. San Francisco, CA: Jossey-Bass, 2001.

Collaboration Leads to Improved Outcomes

1 Reply

The Product Production Process (Part Three)

Being associated with a product or product line is more than just being assigned to a project. To stay in sync with your product team, you must understand the process being used to develop and support your product. This understanding starts by gaining clarity on your role and the deliverables you’re responsible for, and then striving to understand the entire product process. Understanding the cross-functional product activities — information, people, and processes — increases execution efficiency and your effectiveness

A well-defined product production process clearly lays out what needs to be managed, when it needs to be managed, and by whom. In addition, it establishes a common vocabulary and set of expectations from start to finish. Project managers need to partner closely with product management to define the process and gain deeper insight into the business drivers of the project and how they relate back to the product.

A product production process typically has defined stages and phases that apply to all goods and services. There are also core artifacts that are directly linked to these phases (product vision, decision matrix, and product roadmaps). When these deliverables are mapped to the appropriate phases, you create the operational roadmap for delivering your products that looks something like this:

Actuation Consulting - Product Management Training

This process is put together much like a project manager would put together their work breakdown structure (WBS). Fundamentally, the process is meant to show who does what and when it needs to be done. Start by breaking each part of the process down phase by phase. Identify the key components that make up each phase.

Activity Name
Owner of the phase
Contributors who help support the owner in completion of this phase
A narrative description of what is expected at this phase
The actual deliverables are also shown
And some sort of identification of who is responsible for creating each individual deliverable. A color coding system based on function works well.

Being able to create this process on one page allows you to print it out and post it on the walls of your entire team – enabling all parties to remain on the proverbial “same page” at all times throughout the entire product development process. In addition, it allows you to create standardized deliverables that other parties count on to do their jobs. The end result shows everyone involved in the entire process (roles, linkages, and deliverables) – clarifying the hand-offs and increasing overall efficiency. Such rigor ensures nothing is done unnecessarily and everything that is necessary is accomplished.

This type of process identification is extremely important as we embark in the world of Agile development. Agile introduces new roles (product owner, scrum master, etc), new processes, and a new way of thinking. This new way, can cause confusion and anxiety as a team tries to execute and deliver. Mapping the process out, will remove that uncertainty and provide you and the team that path forward to success.