Monthly Archives: May 2011

Rethink your performance plan

 by Prabhakar Gopalan

Tweet this: @PGopalan: Rethink your performance plan #prodmgt #career

Two plans for 1 measure

The prevailing managerial approach in corporations to promote, measure and reward employee growth primarily consists of two plans – a performance plan and an individual development plan – 2 plans for 1 measure i.e. growth.  Every year, employees fill out a performance plan against which they are measured and rewarded e.g. with an annual bonus, at the end of the year.  Then there is a second plan called the individual development plan that has things you want to do in the long term but are not tracked, measured, and rewarded or penalized if you miss, with the same zeal as the performance plan.  It simply remains a wish list.  In other words, it is ok to miss development goals.  You wonder why?

Here’s an idea to rethink this disconnect between individual performance and development in the corporate setting.  Because these two are interdependent and key drivers for growth, shouldn’t  they be in the same plan?  And if they are indeed in the same integrated growth plan, how should the plan be structured?  To answer these questions, let’s look at insights from successful corporate strategy.

Insights from corporate strategy

Enduring companies balance their portfolios in a 3 horizon approach – operate successfully in the short term, develop the vision and incubate technologies, products or services for the long term, and build for executing in the middle term.  A good way to think of this is how Apple approached the market with iPod, iPhone and iPad products less than 10 years.  Apple had the right product marketing mix for the iPod when it came out, worked on the iPhone while iPod was still bringing a lot of cash, and made plans for the iPad much before any competitor even thought of a mass market touch tablet.  Many even questioned if a touch tablet with a form factor between a smart phone and laptop would ever succeed in the market.  What we know now is a different story.  This meticulous 3 horizon planning isn’t unique to a consumer electronics gadget maker like Apple alone.  In The Alchemy of Growth, Mehrdad Baghai, Steve Coley, David White and Stephen Coley write about a 3-Horizon approach for corporate strategy in building the enduring enterprise, citing examples from many industry verticals.  If enduring corporations plan their growth in 3 horizons, and have management processes to measure and reward growth in 3 horizons, shouldn’t employees too have the same 3 horizon growth plan for themselves?  Why would growth for an employee be any different from growth for the corporation?

How to model a 3 Horizon individual performance plan

So, what would be your considerations for a 3 Horizon individual performance plan?   Three things come to mind. First, figure out what would be a 3 Horizon timespan for your business.  For example,  if you are in information technology, it is probably a shorter timespan than a mature industry vertical.   Second, determine what priority or reward percentage you would allocate to each horizon in that timespan.  You could come up with many models for determining this priority (more posts on this in the future).   You could have a 70-20-10 mix if the business needs all the momentum now,  or a 50-30-20 if you already have the momentum going on (e.g. a blockbuster product or plan for the current operating term) and most growth opportunities for the company are in the medium and long term.  Finally, identify drivers in each horizon and how these align your individual growth plan (development needs) to corporate growth opportunities.  For employees this gives true opportunities of growth within the company and for companies there is no better way to retain employees than prepare them for future growth from within.

Innovative companies like 3M, Google, Atlassian give employees the choice to spend their time on projects not necessarily in their job description or performance plan. As Scott Berkun points out, it is more of an attitude and culture at these places than a rule with a manager tracking how much an individual spends time on his projects. But the underlying idea is simple and clear – to build enduring corporate growth, let your employees grow the same way as you’d want the company to grow.  Counting hours on a timesheet worked for the factory age.  It doesn’t work for knowledge workers.

I would love to hear from readers on what kind of management processes their companies have that reflect the managers’ interest in the long term growth of not just the corporation, but also the long term growth of the employees.


Tweet this: @PGopalan: Rethink your performance plan #prodmgt #career

Worth Repeating: Do This or Die!

Given it’s Memorial Day in the US, here’s a small trip down memory lane. I originally posted it a couple of years ago, it’s definitely worth repeating While the manifesto about the need for truth in advertising is from the 1960s or 1970s it’s every bit as true today as it was back then, perhaps even moreso.

Enjoy, and for those in the US, have a great holiday.

dothisordie1A couple of days ago, I recommended one of my favorite radio programs — The Age of Persuasion — to all of you.

I also mentioned that that one of my favourite episodes is entitled “Do this or Die“.

The title of the episode refers to a print ad written back in the late 60s or early 70s that called the advertising and marketing industries to task for talking down or talking at their intended audience. It was a call to action to speak truthfully and to market products that are worthy of being marketed.

Today, there is a lot of hype around social media. YouTube, FaceBook, Twitter, MySpace, blogs, flickr, podcasts, viral videos, online chat, you name it. There’s a lot of options out there. I actually heard a site referencing their corporate voicemail box as their “audio blog”.

People are claiming that all the old rules of marketing are changing. The names vary: social marketing, inbound marketing, viral marketing, word of mouth marketing etc. There are “new rules” for the “new media”.

I’ve even seen articles that use the phrase “Marketing 3.0“!


New media? Yes.

New rules? No.

New tactics? Absolutely, where necessary.

Read that great print ad from almost 40 years ago (text is below). Listen to the audio program from the Age of Persuasion.

They’re both great reminders that the fundamentals of marketing have not changed. The new media is an opportunity to remember and restore the old rules!

My favourite line from this manifesto?

Telling the truth about a product demands a product that’s worth telling the truth about.

What a great line. No pigs with lipstick allowed!

Here’s the full text. Enjoy.


Is this ad some kind of trick?

No. But it could have been.
And at exactly that point rests a do or die decision for American business.
We in advertising, together with our clients, have all the power and skill to trick people.

Or so we think. But we’re wrong.
We can’t fool any of the people any of the time.
There is indeed a twelve-year-old mentality in this country; every six-year-old has one.
We are a nation of smart people.
And most smart people ignore most advertising because most advertising ignores smart people.

Instead we talk to each other.
We debate endlessly about the medium and the message.
Nonsense. In advertising, the message itself is the message.
A blank page and a blank television screen are one and the same.
And above all, the messages we put on those pages and on those television screens must be the truth.
For if we play tricks with the truth, we die.

Now. The other side of the coin.
Telling the truth about a product demands a product that’s worth telling the truth about.

Sadly, so many products aren’t.
So many products don’t do anything better.
Or anything different.
So many don’t work quite right.
Or don’t last. Or simply don’t matter.

If we also play this trick, we also die.
Because advertising only helps a bad product fail faster.
No donkey chases the carrot forever.
He catches on. And quits.

That’s the lesson to remember.
Unless we do, we die.
Unless we change, the tidal wave of consumer indifference will wallop into the mountain of advertising and manufacturing drivel.
That day we die.

We’ll die in our marketplace.
On our shelves. In our gleaming packages of empty promises.
Not with a bang. Not with a whimper.
But by our own skilled hands.

Doyle Dane Bernbach Incorporated



Guest Post: Product Marketers, Where Do You Belong?

NOTE: The following is a guest post by Jennifer Doctor. If you want to submit your own guest post, click here for more information.

Do you work in product marketing? Have you ever tried to explain what you do, to someone who isn’t familiar with product development and management? Ever want to pull your hair out after the conversation?  It probably goes like this:

“What do you do?”

“I’m in product marketing.”

“Oh, so you develop those flashy ads we see all over?”

“No. Product marketing, not advertising or marketing communications.”

“Oh. So what do you do?”

“I make sure that the messaging of my product is something the market will understand, and then work to communicate that to people who want to buy my product.”

“Oh. So you create the sales leads?”

“No. I create the product positioning, work on the launch strategy and help the rest of the marketing teams do their job better.”

“I get it. You’re in marketing.”

“No. I am on the product team.”


It is established that product marketing is a vital and necessary role within any product organization. (I’d go as far as to defend that means that it is necessary in EVERY organization since every company is selling some sort of product.) Yet, too often, product marketing is forced to explain its own value. And, this starts with needing to justify its role and what it is that you do.

Start with understanding what you do

Taken at its core, the basic level, product marketers work to get the “products off the shelf.” … The role works with product managers who are about getting the product on the shelf.

And, product marketing is a partner to marketing services, who drive the lead generation and marketing communication who design the various artifacts that support the product. Yes, these are very basic definitions, but they do separate the responsibilities. There are defined lines that are distinct.

Here is where the challenge comes though. It makes sense, in the majority of organizations, to have the marketing services and marketing communication in the same organization. They are dependent upon each other. And product marketing? Both of these teams depend on the product marketing team effort to do their jobs.

So, some put the product marketing team within the marketing organization. Bad idea.

When you put the product marketing team with the marketing team, the role is challenged to deliver on its true value. Instead, the role becomes one of a tactical delivery vehicle responsible for data sheets, webinars and sales training.

It’s about adding the right value

In an ideal world, the role of product marketing should be aligned in the same team as the role of product management. The two are inseparable since they are both about the product first. Both of the product roles require an outward view to the market at large. Both roles need to work together on the product roadmap.

There are differences too. Product management listens to the market. Product marketing talks to the market. Product management is about getting products ready to be available to the market. Product marketing needs to understand how to position the product so that the buyer is interested. Both teams add significant value to the product. Both teams are necessary to the success of the product. True, together, the work they perform flows to the partnership formed with their marketing brethren. But, separation from product management means splitting the product’s market voice.

Looking in from the outside, where product marketing sits as a role within the organization matters. It matters a lot! If you are seeking to add product value, then align the role to where it has a fighting chance. If you are depending upon the role to deliver a market voice about the product, then align it with the product.


Tweet this: Product Marketers, where do you belong? New post by @jidoctor #prodmktg #prodmgmt #leadership

Jennifer Doctor, a strong advocate of ProductCamps, is an independent product marketing and management consultant, working with companies to help them understand their markets, buyers and how to better enable sales teams to deliver results. She maintains her own blog – The OutsideIn View – and can be reached at Jennifer dot doctor at gmail dot com.

How can Win/Loss Analysis help you find untapped markets?

By Alan Armstrong

This week had a very smart CEO pose a great question to me:

What are we missing in terms of opportunities where we aren’t even considered? Frankly I worry (like all paranoid startup CEOs) that this may be the biggest opportunity for growth.  Do you have any hypothesis on how to dig in to that category of clients that have not heard of us?

One of the problems with Win/Loss Analysis is the focus on accounts where your company is already engaged. Can this analysis help you find untapped markets, or accounts where you are not being considered?

This is a crucial question for anyone concerned with product or corporate revenue – investors, product managers, sales VPs, marketing VPs.

I give my answer below, but first, here is a quote from Donald Rumsfeld that explains the problem more fully. Rumsfeld took a lot of heat for this quote, and perhaps it was overly obtuse or intellectual for the press. But if you listen to what he says, it’s remarkably insightful:

In marketing / sales terms, here’s what Rumsfeld is describing:

  1. Known knowns: These are accounts that you know how to go after. This is your sweet spot in the market. Hopefully you have one or more of these!
  2. Known unknowns: If you are paying close attention to your company’s deal flow, there will often be deals that are outside of your sweet spot. Even by accident, your customers will use your product in ways that you hadn’t imagined. You have to be paying close attention to notice these, but when you see one, you should take note of it and dig in to their business need, how they found you, and whether they need any additional capabilities. These accounts present a potential opportunity to expand your market. When you profile these accounts, pay very close attention. Once you notice them, you can use their profile to size the market, and if it appears attractive enough, create a pilot marketing/sales program to go after a short-list of these accounts.
  3. Unknown unknowns: These are the potential opportunities that you and your customers haven’t thought about yet. Are these potential accounts buying your competitors’ products? Perhaps your competitors have discovered them before you, or maybe they are just struggling with a problem that you could solve, but no one has put two and two together.

Back to the CEO’s question: How do we find the Unknown unknowns, the untapped markets?

I call these markets “hidden market segments”. So how do we find these hidden segments? Here are my suggestions:

Pay attention to patterns in your deal flow

One possible difference between #2 and #3 above is that in #2, you are paying attention, and you notice the anomalies in your deal flow. It takes an intuitive person to notice such anomalies. But it should be a priority for everyone paying attention to the deals. If you need to get started, Win/Loss analysis is a great technique. Unfortunately many people don’t do a good job of win/loss analysis. (I wrote about some bad techniques earlier. Steve Johnson covers his views on Win/Loss here. ) You need to ensure that you are studying the whole buying process, speaking directly to buyers, not accepting the reasons given by sales. Too often companies note just the final reason for a win or a loss, but you need to avoid that temptation and look at the whole buying process.

What about the Unknown Unknowns?

The problem with the bucket #3, customers that you don’t know about, is a bit circular! Philosophers would call this an episemological problem … it is an unknowable thing.

While it is difficult, much of the difficulty can be solved in two ways:

  1. Turn #3 into #2 by consistently profiling your wins and your losses. See above. (If you need help, contact me. I do this for a living.)
  2. Look for hunches: If your deal flow is too large to profile consistently without huge sampling bias, start by interviewing people internally. Look around for hunches. Frame the question as I have done above. Start by profiling your sweet spot, and find some really smart, market/customer-centric people inside your company. Explain to them that you are looking for people outside your sweet spot. Once you find some potential anomalies, start your Win/Loss analysis with accounts similar to the anomalies. With 5 wins and 5 losses, you’ll have a good start.
  3. Look at your competitors successes: Are they winning outside your sweet spot? Are they attending tradeshows or hosting events for use cases that you hadn’t considered? Can you find lost accounts in your past that represent cases like these?
  4. Brainstorm and Sell: What are the potential uses for your product in markets where you’ve never (knowingly) won a deal? Can you put together a pitch deck identify 5-10 sample accounts, and go after them with a SWAT team? You need BD-type people, not sales-types for these markets because you are breaking new ground.

In the end, it all boils down to finding a new profile of customer. You need detective skills, market knowledge, buyer knowledge, and sometimes good luck, but it can be done.

- Alan

The Product Management & Product Marketing Backlog


In the Agile world, the key to product success and a driving cadence is the product backlog.  If managed well, the backlog balances strategic initiatives and tactical features. What would happen if product management and product marketing professionals adopted and used backlogs?

Will a backlog drive strategic thinking and provide clarity?

It’s my hypothesis that product management and product marketing teams can be more effective, increase strategic actions and build cadence when they identify, prioritize and build a backlog focused on their roles.

From a Historical Perspective
Whether you work in an organization where Agile or Lean principles (SCRUM, Kanban, etc.) have been adopted, I’d bet most of your product management and product marketing thinking is still list or task-driven or formulated on-the-fly.

And forget about priorities. They change with the whim of the organization or the latest Flying Monkey.

Most product management practices, training and tools are focused on non-iterative actions. While their tenants and intentions are good, it’s been my experience that product management and product marketing mask their organizations engineering process and it cascades into their thoughts, actions and focus.

The Hypothesis
My hypothesis was to test this with a diverse group of product professionals (preferably ones I didn’t know) and together surface where we’re spending our time and build a backlog of new thinking.

I attended the DFW Product Camp and led a session of 26 people. The session was represented by the following categories:

  • Product Management (8)
  • Product Marketing (4)
  • Marketing (8)
  • Those leading Product Management and/or Product Marketing (3)
  • Other (Included a CEO and consultants) (3)

The Exercise
With limited time, we decided to choose Product Management to test the hypothesis. In a PowerPoint-free zone, (thanks Seth Godin) we began by identifying four themes that included:

  • Planning and Strategy
  • The Now Product
  • Communications
  • Tools and Process

In each of these areas, I asked the group to identify and write down topics where they spent most of their time and post them under the themes.

It’s no surprise that topics such as; Crisis Management, Tools Implementation, Sales Demos, Customer Issues and Product Features surfaced most often. The picture below represents the number of items that appeared.

I then asked the group to think about and prioritize the areas they would (and should) spend more time. From the image to above, it’s evident that more strategic areas focused on Strategy and Planning, as well as The Now Product were desired.

The highest number of votes included:

  • Strategy development and alignment
  • Market definition
  • Clarify strategic vision
  • The Compelling Why
  • Market Research
Creating a Balanced Backlog
In his article Product Backlog Rules of Thumb, Chris Sterling describes several rules for successful backlogs. For product professionals, I would recommend the following:
  • Keep your backlog simple
  • Define both strategic and tactical areas
  • Prioritize your backlog (The most important is where you start)
  • Select one to three items to focus and work on
  • Infuse these in your daily schedule (If you have to block time, do it)
  • Look to peers for knowledge and help
  • Infuse your strategic actions into your culture

The Results
While the hypothesis is yet to be validated in a live organization (I’d like to hear from the attendees in the future), it shared consistent ideas and challenges. Product Camps are a great place to gather input and test ideas like this. Have you committed to attend a PCamp in 2011?

As a product professional, would a prioritized backlog improve your thinking and execution?

I welcome any experiences as well as comments. If you’d like to post this on Twitter or LinkedIn, please share:

Tweet or Link this: The Product Management & Product Marketing Backlog a new post for #prodmgmt #prodmktg #leadership



Addressing Market Shifts or Why RIM is not down and out just yet

by Saeed Khan

If you’ve read anything about Blackberry maker Research in Motion (RIM) lately, it’s likely that the news has not been good.

Whether it was the underwhelming response to their Playbook tablet, the abruptly ended BBC interview by Co-CEO Mike Lazaridis, or the recent drops in RIM’s stock price, negative news seems to have a death grip on the company.

People are looking at the growth of iOS (Apple) and Android based phones, with RIM dropping to a distant 3rd in market share.

But in all of this doom and gloom, it’s too early to count RIM out,  and there are real lessons to learn about dealing with shifting markets and new competition against established players.

First, let me say that while I’m a big fan of RIM for a number of reasons, I don’t have any financial stake in RIM.  Second, I don’t have any “inside” information that I’m sharing. This post is an outside-in view of RIM, trying to look past all the noise in the news channels, and analyse the situation from a Product Manager’s viewpoint.

The market has changed

I remember when the first colour Blackberry’s were introduced. Wow. Nice screens and they got rid of the thumbwheel and replaced it with the trackball, which later became a small trackpad.  Those seemed like big changes for RIM.  But to state the obvious, Apple completely upended the game with smart phones, and for a while, RIM seems to have been caught snoozing.

RIM’s initial forays into more “iPhone”-like touchscreen phones were the Storm and the Torch. Neither met with major success. They were simply me-too products when compared to the iPhone, and poor ones at that.

But RIM is not simply a handset company. RIM provides infrastructure to both carriers and enterprises. For carriers, RIM provides billing services, secure and efficient email and data transmission, and device management services. For enterprises, RIM provides the Blackberry Enterprise Server (BES) for provisioning and managing the devices.

These are clear differentiators when compared to the iPhone or Android devices. They are why both carriers and enterprise IT favour the RIM devices. And these are the likely reasons why RIM did not react more quickly to the threat of consumer-oriented touch-based smart phones like the iPhone.

Battleships turn slowly

But RIM is changing, and while it may not be clear to all, the Playbook tablet is key to RIM’s transformation.

Sure, people are complaining about the Playbook, the lack of apps and email integration etc. But RIM is not in the tablet business. They’ll definitely sell their share of tablets, though nowhere close to what Apple with sell.

The reason that the Playbook is important is because it, and more specifically the QNX operating system it runs will be the foundation of the next generation of Blackberrys. This fact was announced last fall, though it seems little attention has been paid to it by the broader press.

In short, the Playbook is the lab, before the new Blackberry factory gets into gear. This is a critical point to keep in mind.  For established companies like RIM, change will rarely happen rapidly, given the technology, systems, processes, contracts and other business issues to deal with.

But then, are RIM’s customers demanding change overnight? How fast can RIM’s customers, mostly enterprises, consume any change? And at what cost? Would they trade off speed of delivery vs. stability, security and management? And if so, why?

These are some of the important question to ask when addressing significant market shifts.  And once you have the answers, a strategy can be put into place to manage the change.

The road ahead

There are still many challenges ahead for RIM.

  • They definitely need to get their new QNX based Blackberrys out soon, ideally in 2011 and NOT 2012.
  • They need to create, educate and grow a thriving 3rd party development community.
  • They need to acquire (or seriously partner with) mobile application or cloud service companies to provide differentiated capabilities for enterprise and business users
  • They need to provide incentives to existing customers who move to the new QNX Blackberrys vs. losing them to iPhone/Android handsets.
  • They need to show the market and investors that they are still an innovative company that can deliver rock solid products.

While the market will give Apple slack for things like AntennaGate, or taking a very long time to ship a white iPhone, it’s unlikely the same grace will be given to RIM. Let’s face it, Jim Balsillie is no Steve Jobs.

So, even though the market for smart phones has shifted, and forced RIM into a defensive position, it’s clear they have a plan and are executing on it. Given the storms RIM has weathered in the past, if history is any indicator, RIM will make the shift from old to new platform, despite the doom and gloom predicted by many pundits. It may never be as sexy as Apple, but then who is? But in the end, there is nothing wrong with a profitable, $20 Billion dollar company. :-)


Tweet this: Addressing Market Shifts, or Why RIM is not down and out just yet. #prodmgmt #strategy #innovation

A new (and better) definition for Product Owner

by Saeed Khan

Last week’s post entitled “The Scrum Title ‘Product Owner’ must die!“  on changes to the Scrum “Product Owner” title and responsibilities drew a lot of comments and feedback. Some agreed, some disagreed, but clearly there is much room for improvement in how that role is defined and implemented.

And thus the genesis of this post. It’s time to provide a better, more applicable and less convoluted description of the “Product Owner” role so that companies who are implementing Scrum can do so with far less confusion and tumult in their organizations.

One reader, Rohan, left a great comment that is worth repeating and discussing.

Given that the role of Product Owner is a requirement in Scrum, and given that the name “Product Owner” is well established there, I think that “must die” is admirable but futile. I think we have a much better chance of success if we focus on educating people that Product Owner is a role, not a job title, to be filled by someone with a real job title like (in many/most cases) Technical Product Manager. Then the existence of the term “Product Owner” can be limited to members of the Scrum team, and the rest of the world can be spared. That is, I don’t think we can kill the term, but we can quarantine it.

Well said Rohan.  I must say that the “must die!” title of the previous post had a lot to do with having a provocative title to draw readers. I think it worked. :-) And while it’s true that it would be difficult to displace the name “Product Owner”, it doesn’t hurt to get people thinking about it. But I have to agree that quarantining it is much more likely to happen. So, let’s get started.

The problems with the current definition

To review, I saw two problems with the “Product Owner” title and description. In short they were the title and the description.  But seriously…

  1. The name “Product Owner” and particularly the word “Owner” causes confusion when Scrum in implemented. Does anyone actually “own” the product? And if so, is that person (most likely someone very senior) going to spend time with the Scrum team, in daily standups etc.? No.The name derives from the Engineering-out view of the company. i.e. Engineers want “one throat to choke” when it comes to business requirements and ensuring their work aligned with “the business” side of the house. i.e. from their perspective, that person is the owner of the product, regardless of whether that is the case in the company at large.
  2. The responsibilities of the “Product Owner” (as defined by Scrum and it’s advocates) are a convolution of business and technical, strategic and tactical responsibilities, that in reality are never seen in a single individual role. There needs to be a distinction made between what the “Product Owner” actually does and what he/she represents.

BTW, in researching what others had written on this topic, I came across this series of posts by Luke Hohmann on why prioritizing backlog by ROI doesn’t make sense. Luke is no outsider when it comes to Agile and Scrum and this series of articles is worth reading.

Constraints for a new defintion

So, back to the topic at hand. Given the issues with the Product Owner definition, how can it be changed to be better and more clearly defined and applied within environments? Let’s look at some of the constraints that the definition must fit into.

  1. It must cover both internal IT projects and commercial products, and also be relevant to applications built for specific customers by consultants.
  2. It must focus on the need for ongoing business input into the development process
  3. It doesn’t define a new role that duplicates existing roles.
  4. It must adhere to the Scrum requirement of a “single throat to choke”
  5. It must be a job that can actually be done by one person. No superheroes required

The new (and better) defintion

Given these criteria, here’s a proposed NEW and (IMHO) better definition of Product Owner. To compare and contrast, read the Jeff Sutherland definition in my previous article.

1. It’s a Role not a Title
The “Product Owner” is a role (and not a title) aimed at addressing a key problem that has historically plagued software development projects: that being the gap between business priorities and the work executed by software development teams. The result of this problem is a long history of projects and products that did not meet customer or market needs and that were either delayed or required extensive additional work to meet requirements.

2. Primary interface to the Scrum Team
The “Product Owner” is the primary interface of the business with the Scrum Team, and is responsible for ensuring a prioritized backlog is maintained so that each successive Sprint can be planned clearly and efficiently.

3. Actively addresses ambiguity and change
Given that requirements can be open to interpretation, and business priorities can change over the course of a project, it is imperative that a representative of the business be actively engaged — ideally on a daily basis — with the Scrum team to ensure development decisions stay aligned with business needs, and any issues that arise are addressed as quickly as possible.

4. Different titles can be “Product Owner”
For internal IT projects, the “Product Owner” may be represented by a Business or IT Analyst or even a direct End-User representative. For products targeted at wider markets, the “Product Owner” may be part of the Product Management team – e.g. a Product Manager or Technical Product Manager. And for consulting projects, it’s likely that the “Product Owner” is a direct representative of the end customer and not a proxy for them.

5. Is most likely NOT the sole business decision maker
It is understood that the “Product Owner” represents the business needs to the Scrum team but may not be the sole decision maker in the business priorities. i.e. While they interface with the Scrum team on one side, they will be interfacing with other parts of the business, or in fact directly with the end customer.

6. Must be technical enough to deal directly with the Scrum team
Given the technical nature of software development, the “Product Owner” should have a sufficient technical background to engage with the Scrum team when technical issues arise that impact delivery of business requirements. This does not mean the “Product Owner” has to be as technical as a Developer, but sufficiently knowledgeable to fulfill the bridging role between the business and technical sides of the project.

7. Not necessarily the ” single throat to choke” from a Scrum team viewpoint
While the Scrum team views the “Product Owner” as THE  representative of the “customer”  — singular or multiple — and their requirements, this cannot be universally true. While it *may* work for a given project for a particular (singular) customer, when it comes to software products targeted at market segments, the “Product Owner” may not have full authority for all decisions needed to be made and thus the Scrum team must be aware that some issues will need to be escalated up the chain to more senior people in the Product Management or Executive team.

So there you have it. While not as short as I would have liked, the above definition meets the constraints set out earlier in the post. It’s clear to me. What do you think? Does it address the “traditional” problems with the “Product Owner” role? Does it create any new ones?


Tweet this: A new (and better) definition of Product Owner #scrum #agile #prodmgmt

The Factory vs. The Lab: Leaders know which is which, and mistakes are costly



Teams requires both a laboratory, to innovate and design, and a factory, to build and deliver. Unfortunately teams, companies, and individuals spend too much time in the lab or the factory, and often confuse the these two very different environments. In doing so, we frustrate ourselves and fail to capitalize on significant opportunities.

A tale of two teams

I recently interviewed two VPs of Operations for major US wireless carriers. They provided very different outlooks on situations that are in many ways nearly identical. Both had sprawling infrastructure as a result of decades of acquisitions, divestments, new product builds, and so on. And both had been recently appointed to get things under control.

The first VP, Edgar, expressed serious frustration and fatigue. He described a team fighting fires and always behind schedule. But what felt most overwhelming they were not moving forward fast enough to catch up. The team was also stressed out, and sick leave had increased. According to Edgar this was just making things worse – with fewer employees at their desks, they were getting more and more behind.

The second VP, Jack, gave a distinctly different perspective. Jack described the current state of measuring, learning, and observing; “We are learning about the environment and how it behaves.” Soon, he said, they would start experimenting with some improvements.

Turning the factory into a lab

Jack had turned his factory into a laboratory, where the team’s job was not just to keep the lights on, but to invent new processes, techniques, organizations, and technologies to make things run more smoothly. If he viewed that operation as a factory, it would be judged a huge failure. But viewed as a lab, it can be seen as a place full of upside, with opportunity for a lot of creative thinking, growth, and empowerment. If the boss things that way, it flows to the team as well.

The lab vs. the factory

The lab has very different kinds of thinking than the factory. In the lab, we set goals and make hypotheses, but no one pretends to be able to predict the outcome or the timelines with great certainty. When we release that need for certainty, we open ourselves up to experiment. It’s called trial and error for a reason; we expect errors to occur, and that is in fact how we learn and ultimately how we create something new.

Once the mindset is changed, the team starts to have fun again. We realize that we’re trying something without a predictable outcome, and so we just do our best, make our best attempts, debate hypotheses, design tests, but everyone realizes that we are in fact experimenting. Everyone relaxes a little.

Managing external expectations

If any leader decides to change modes from factory to laboratory, it is critical that the leader manages external expectations. If we are working in the lab but management or other stakeholders are expecting our usual factory delivery, they will be frustrated and disappointed. Missing expectations is a serious career limiter for any leader.

The leader’s job is to reframe the activity and persuade external stakeholders to change mindsets. If persuasion is not your game, you can also give them a choice: “We can use our factory and produce X, but if you really want Y, we need to use the lab, and that will be more expensive and take longer. We can’t guarantee success, but here is what we think we can do, and we believe you’ll be very pleased.”

Nail it. Then scale it.

“Nail it. Then scale it.” is my company’s tagline, but it’s more than just a marketing slogan. I see it as an approach to many tasks and situations. I coach my clients, employees, and friends (and myself!), to apply this philosophy many areas of work life, and even some areas of personal life. If you are trying to produce something at scale without understanding the basic mechanisms and tasks, you will suffer great frustration and likely fail. It takes patience to recognize areas that need to be ironed out before they can be successfully repeated over and over. You have to nail it before you can scale it. When we are in the lab, we our job is to nail it. It is a common and often disastrous mistake to try to scale it before we nail it.

Step 1: Become conscious of the difference between factory and lab

The first step is to become conscious of the difference between the factory and the lab. I encourage you to ask questions like:

  • What does this project or task require: factory thinking or lab thinking? Or perhaps a combination? What combination?
  • Am I creating a burden for me and my team by expecting a factory, when I really need to create space for a lab?
  • Does my drive to “be creative” cause me to treat everything like a lab, even with tasks that need to become routinized and automated? If I treat the factory like a factory, can I open up more space for truly interesting lab work?

Stay tuned for the next instalment where I will talk more about the implications of lab and factory thinking for organizations.

- Alan

PS: If you liked this post, please share it on Twitter, LinkedIN, or Facebook!

The Factory vs The Lab: Leaders know which is which, mistakes are costly. #leadership #prodmgmt #prodmktg via @ONPM

Onboarding Product Management – Mind the Gap

Recently I was talking with Michael Hopkin, author of Lead on Purpose. I asked Mike, “How often do you see product management and product marketing leaders doing a good job of on-boarding new team members?” His response, “Not often enough.”
I thought about the signs that emerged on train platforms in the London Underground. How can product leaders Mind the Gap and ensure successful on-boarding of newly hired team members?

Why is On-boarding Important?

According to Wikipedia, “On-boarding refers to the mechanism through which new employees acquire the necessary knowledge, skills, and behaviors to become effective organizational members and insiders.”

According to the Society for Human Resource Management, “A documented process or schedule of activities may make a new employee to an organization or location feel welcome and comfortable sooner rather than later.”

From a product leaders perspective, can you afford to fail at on-boarding? If you miss the opportunity of building knowledge, setting expectations, clarifying roles and building team cadence, when will it happen?

Isn’t on-boarding HR’s job?
While Human Resources plays a key role in on-boarding, they generally provide introductions and overviews of the company, make sure new employees have essentials material such as benefits and wellness packages, payroll and tax forms and answer questions while coordinating equipment (hardware and software), IT services and ready work spaces, and review company-oriented documentation and procedures.

In essence, HR  facilitates and introduces, while leaders of product management and product marketing buildenable and launch contributor success.

Too often product leaders expect HR to do the full on-boarding and deliver new employees ready-for-action. In complex roles like product management and product marketing, this does not work.

Three Elements of Successful Onboarding

In the post, Onboarding 101, Morgan Hoogvelt suggests their are three basic elements a successful on-boarding.

  1. Participants - identify who is going to be part of the process and who will be participating in the on-boarding program. Each participant should have a full understanding of the program in order to deliver a productive and consistent message.
  2. Material – have a defined plan of action and itinerary. Topics may include: welcome message, company history, products/services, competition, policies/procedures, department briefings, etc.
  3. Timeframe: as mentioned above, the recruiting process should be ongoing and never stop. This will enhance employee engagement and communication which may help to reduce turnover and keep employees happy over the long run.

Elements for Onboarding Product Management and Product Marketing

Mike and I discussed the minimum criteria that leaders of Product Management and Product Marketing should consider and champion for successful on-boarding. They include:

For Both Roles:

  • Review the roles and responsibilities (the real ones, not the ones posted in the job description)
  • Discuss and agree on assignments and expectations. (Ones that weren’t discussed in the interview process.) Eliminate any confusion upfront.
  • How is the role measured? (You have measurements in place don’t you?) If not, read this.
  • Review the organization and how the roles works within and with other teams such as Development, Engineering, and Marketing.
  • Share insights into who the Executives of Influence are in the organization, what role they provide and how to work with them.

For Product Managers:

  • Includes the items listed for both roles, plus…
  • A plan to obtain a knowledge and understanding for the product(s) they will guide.
  • How product management communicates and through which methods are preferred.
  • A review of the product strategy and existing roadmaps (You have a strategy and roadmap in place, right?)
  • How the products are packaged, priced and positioned.
  • Introductions to product and customer knowledgeable teams such as Sales Engineering and Customer Support.
  • A current list and introduction to top customers and non-customers. (Connect product management as soon as possible.)
  • Others that are specific to your organization and team.

For Product Marketing Managers:

  • Includes the items listed for both roles, plus…
  • A plan for the Product Marketing Manager to obtain an understanding of the product(s) and their strategy.
  • The current positioning, competitive landscape and personas associated with the product.
  • Review the Product Marketing roadmap. (If you don’t have one, read this post.)
  • How product marketing communicates and works with Marketing.
  • The process used for discovering market problems and artifacts Win/Loss Analysis, Customer Interviews, etc.
  • A review of industry analyst information and introduction to customers willing to talk about their buying process and use of the product.
  • Other items that will allow the person to better understand the role, responsibilities, strategy

Minding the Gap

The same natural drive and curiosity that compels individuals to become product managers and product marketing managers drives them to dive into their new role and come up to speed using any resources and methods possible.

However, perceptive product leaders should develop a plan to focus on the first few weeks, the first 30, 60 and 90 days and provide guidance. To give new team members the best possible on-boarding experience,  assign another team member to answer questions, mentor (if necessary), provide insights, experience and information from the first day going forward.

As a product leader, schedule 5-10 minute discussions each day in the first week to understand and surface gaps in the process. After the first week, schedule 10- 15 minutes each week and if possible, use team meetings to support the on-boarding process. If no one else is available, it’s your responsibility.

Thanks to Mike Hopkin for his collaboration and contribution to the post.

If you like the post, please retweet: Onboarding Product Management – Mind the Gap, a new post for #prodmgmt #prodmktg #leadership

I also welcome your comments and insights as to how you have successfully onboarded a new team member or been a recipient of great on-boarding.

The Scrum Title “Product Owner” must die!

by Saeed Khan

There was a tweet this past weekend that caught my eye. It said something like “The Product Owner on one page”. It was retweeted many times.

When I looked at the link in the tweet I saw the image shown below. I thought, “Geez, now the Agilists are turning the Product Owner into some kind of superhero Product Manager?”. And we know what a problem that is. :-)

I had to write something to help clarify this never ending debate about what a Product Owner should be.

I’ve written about Agile previously on this blog, but it’s been a couple of years since I delved into the topic at any length. Before I begin, and before people misinterpret what I’m about to say, let me clarify a few things up front.

  1. I have nothing against the general concepts of Agile or methodologies like Scrum (or XP etc.). If tightly-coupled teams make for better communication and better results, then great.
  2. I’m not criticizing any particular individual, even though my examples may appear that way.
  3. It’s the title and overall definition of “Product Owner” that must change, not the need for some form of business focused oversight on software development projects that Product Owners typically deliver.

That aside, let me get started.

I have never liked the title “Product Owner”. It’s a very narrow-minded view of the term “product” and is not even consistent with it’s own description.

On the Scrum Alliance site, in the sidebar, you can see that Product Owner is listed as:

Responsible for the business value of the project

Yes, it says business value of the project, not product. BIG difference. But other than that, the description is very general, and quite  open to interpretation.

On Wikipedia, the Product Owner is described as:

he/she “who represents the stakeholders and the business”

Again, a fairly general description, but in short if you look at these two together, they seem to describe someone who has the business interests in mind for a given project and ensures that value is delivered back to the business.

It’s pretty clear that in the early discussions of Scrum, there was clear evidence for the need to have “the business” represented as part of the development process. Far too many projects floundered because of lack of input and alignment with business needs. So the problem being addressed by a “Product Owner” role was valid.

So the question is, how did the title “Product Owner” go from this high level general description as an overseer of the business interests for a given project, into what is a much larger singular role with broad strategic and tactical responsibilities that is described by the diagram on this page. (shown below).

Product Owner on one page - Roman Pincher

From one of the founders of Scrum

To find the answer, I decided to go to primary sources. Thank goodness for the wealth of info on the Web. Very quickly I came to Jeff Sutherland’s site. Sutherland, along with Ken Schwaber and others were amongst the earliest advocates of Scrum and were instrumental in it’s definition, development and growth.

Sutherland has a draft PDF of his book, The Scrum Papers: Nuts, Bolts and Origins of an Agile Framework available on his site. There’s a lot of good content in the 200+ pages, but there are also some problems.

The first key description is that of Scrum itself. On page 16, Scrum is defined as:

Scrum is an iterative, incremental framework for projects and product or application development.

There is nothing inherently wrong with this sentence, but it’s important to note that 3 contexts (projects, products, applications) are to be addressable via Scrum.

And on page 17, Sutherland describes Product Owner. Now, I’ll give some leniency as it’s a draft from Jan 2011, and he may have clean up the definition a bit, but the overall definition of Product Owner is a real mish-mash and clearly needs to be changed significantly to address the ongoing confusion in the market about that role.

The description from Sutherland’s draft is  a bit long so I’ve broken it up for easier digestion and analysis. But read through all of the following as it’s the source of the whole problem with the Product Owner role.

The Product Owner is responsible for maximizing return on investment (ROI) by identifying product features, translating these into a prioritized list, deciding which should be at the top of the list for the next Sprint, and continually re-prioritizing and refining the list.

The description starts out reasonably clearly, with the Product Owner taking on the role of an analyst, identifying and continuously prioritizing features. In many companies though, this process of collecting, understanding, prioritizing etc. is likely done by more than one person so right from the start, putting all of this on one individual is an issue.  But then the description gets downright problematic. He continues:

The Product Owner has profit and loss responsibility for the product, assuming it is a commercial product. In the case of an internal application, the Product Owner is not responsible for ROI in the sense of a commercial product (that will generate revenue), but they are still responsible for maximizing ROI in the sense of choosing – each Sprint – the highest-business-value lowest-cost items.

In practice, ‘value’ is a fuzzy term and prioritization may be influenced by the desire to satisfy key customers, alignment with strategic objectives, attacking risks, improving, and other factors.

First of all, why make this distinction and give the “Product Owner” of a commercial product profit and loss responsibility? There’s no reason for that in the context of a software development methodology. P&L is a pure business function, and may not even rest within a Product Management organization, let alone a someone whose primary role is interfacing with Engineering teams.

On the plus side, I’m glad to see the recognition of the fuzziness of value and that it can be determined in different ways. But the use of the phrase “high business-value lowest-cost items” is incorrect as medium- or even high-cost items can be prioritized above lower cost requirements based on need and business value.

In some cases, the Product Owner and the customer are the same person; this is common for internal applications. In others, the customer might be millions of people with a variety of needs, in which case the Product Owner role is similar to the Product Manager or Product Marketing Manager position in many product organizations.

OK…now here’s where the description has some other problems. Sutherland acknowledges that there is similarity between the PO and PM or PMM roles, BUT:

However, the Product Owner is somewhat different than a traditional Product Manager because they actively and frequently interact with the Team, personally offering the priorities and reviewing the results each two- or four-week iteration, rather than delegating development decisions to a project manager.

So, more communication is great and there’s nothing wrong with having someone from the Product Management team be more actively engaged with the Engineering team, but then why not just say that’s what is needed as part of the methodology. i.e. a new role that must “actively and frequently interact with the Team…” and not include unnecessary baggage such as P&L.

It is important to note that in Scrum there is one and only one person who serves as – and has the final authority of – Product Owner, and he or she is responsible for the value of the work.

This last line of the description – about having a single responsible person for the value of the work of “the Team” – needs work. The problem here is that for a “Product” there may be many Scrum teams and there is no way a single person can have regular and detailed interaction with those teams, continuously prioritize (and reprioritize backlogs) etc. i.e. this model works for simple “products” but breaks down for larger ones.

So what is the solution?

I’m glad you asked. :-)

From a Development perspective, the core issues that need to be addressed are:

  • the need for ongoing backlog prioritization
  • the necessary interaction with the Development team so they can make progress on the backlog and stay aligned with the needs of the business.

That’s it. Everything else, from P&L to budgets, to roadmap and vision (as shown in the diagram above) are irrelevant. In most companies, those responsibilities already have owners so there is no need to muddy waters and blend them into the “Product Owner” role.

The “Product Owner” is part of a team — i.e. the Product Management team — and is the primary interface of that team to the Scrum Team.  For a large product, if there are many Scrum teams, there may be multiple “Product Owners” working with those teams. i.e. there may be multiple “Product Owners” that are part of Product Management.

Thus the name “Product Owner” is itself confusing, if not inappropriate. the following are all better titles than “Product Owner”:

  • Project Owner
  • Technical Product Manager
  • Backlog Manager
  • Customer Advocate

There may be others.

As a “role”, the term “Backlog Manager” seems reasonable.

As a title, “Technical Product Manager” (TPMs) is best, particularly for companies building commercial products. It’s unambiguous…the person is part of the Product Management team, there can be multiple TPMs working with multiple Scrum teams (not necessarily in a 1:1 relationship mind you), and they have a clear technical focus.

It’s time to end the confusion.  The “Product Owner” is dead. Long live the Technical Product Manager.


Tweet this: The Scrum Title “Product Owner” must die! #prodmgmt #agile #scrum #innovation

See my follow up post:  A new (and better) defintion for Product Owner