Monthly Archives: July 2012

Product Management and Product Development Facts

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!

Share via email

The Science of Project Management: 4 Tips to Success

Leave a reply
Checklists, Tools and Templates

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:

  1. Use your experience: consider the problem and try to make sense of it.
  2. Form a conjecture: When nothing else is yet known, try to state the explanation, to someone else.
  3. Deduce a prediction from the explanation. If you assume #2 is true, what consequences follow?
  4. 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.

Share via email
Methods executives use to drive product team alignment

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.

  1. Strong executive support for the core product team
  2. Shared organizational goals and objectives linking the team
  3. Bonus compensation linked among core product team members
  4. Product production process mapped so that all the team members understand their role and handoffs
  5. 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

Source: The Study of Product Team Performance, 2012. Copyright Actuation Consulting. All rights reserved.

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.

 

Share via email

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.

Share via email

Product Strategy’s Vanishing Act

3 Replies
Actuation Consulting - Product Management Training

Bridging the Gap Between Company Strategy and Tactical Product Roadmaps

Part of the Product Management Facts Series

Last week David Heidt, the President of IIBA Chicagoland, and I were doing a webinar for AIPMM on the five factors that drive high performance product teams. As we neared the end of the material I was asked a question from one of the attendees regarding the difference between product strategy and a product road map.

Seasoned product managers might wince a little at the question but it’s becoming increasingly clear that organizations are not making a distinction between these two activities. In fact, industry data points to a growing problem. More organizations are relying on tactical product road maps and clearly defined milestones in the development process as the primary mechanisms to achieve alignment with the company’s overarching business strategy, goals, and objectives!

This is a worrisome development as the data indicates that 36% of organizations are relying on tactical activities as the primary bridge to attaining the product’s goals and objectives in support of the business strategy. And the facts actually get even worse.

The survey respondents went on to state that approximately 15% of organizations actually have multi-year product strategies defining the strategic path of their products worldwide. And when respondents were asked how effective this tool was only half said that their product strategies were effectively deployed – 7% of organizations! This is a staggeringly low number.

So it should not come as a surprise that there is confusion about the difference between tactical product road maps and multi-year product strategy. Based on the numbers it  appears that the majority of organizations are struggling with not only the concept but with finding the right skills to successfully deploy the tool.

We believe that product strategy is not optional. It’s an essential element of ensuring appropriate alignment between your company’s business strategy and objectives and the daily activities of the product team. Before I explain why we feel so strongly that product strategy is essential let me explain the difference between product strategy and tactical product roadmaps.

A product strategy is not a list of capabilities, features, or functions. The components of a product strategy are aspirational and need to be directionally correct since very few individuals have proven that they can look into the future with any degree of clarity. There are some visionaries that have been successful at this, for example Steve Jobs.

Examples of things that might show up on a multi-year product strategy include how you intend to evolve your product from one size fits all, to a tiered product offering, and eventually multiple products. Or perhaps you envision your product moving beyond its current domestic positioning and you want to target international expansion via high probability international markets with an eye toward global availability. In each of these examples there is a clear progression from one strategic stage of product strategy to the next.

A tactical product roadmap by comparison will not chart the strategic course of your product into the future but rather document the releases or tactics (features, functions and capabilities) that you intend to bring to market over the next six to twelve months. The road map helps ensure that your team is focused on execution, that stakeholders know what to expect, and helps with resource planning.

Tactical road maps are limited in their view and tend to be more granular in their scope. Product strategies are aspirational in nature but act as the bridge between company strategy and tactics by explaining how the product management organization intends to stay on a course of continued growth in market share, revenue, or margin. The tactical road map  should support, and move in unison with, the product strategy just as the product strategy should support the overarching company goals.

The facts are indeed troublesome since product strategy appears to have pulled a vanishing act, not by intent, but by the fact that successful product strategy requires product managers that have the ability to forecast the future with a degree of certainty, which requires skill. Additionally, resource constraints, product development process transitions and role changes, and hiring freezes have all adversely impacted the product management organization’s ability to think more strategically.

But without a product strategy to ensure improved alignment between the strategic and the tactical and to help the entire product team understand where the product is headed how will you know what the path to success looks like?

 

Share via email