Month: June 2011

The main thing is keeping the main thing the main thing, Part 2

A good friend and colleague of mine, Michael Papanek, once implored me to “keep the main thing”. In fact,

The main thing
is keeping the main thing
the main thing

(He’s quoting Stephen Covey)

Earlier, I wrote about what the main thing is in product management.

Perhaps the next question is, “what is the main thing?” for your company? And for you?

I once led product management at a company when I paid almost no attention to product features. It wasn’t because I was in product marketing. It was because the product was fairly baked, but we were having a very hard time selling it. So I rolled up my sleeves and got directly involved in the most important deals in the funnel. This was confusing for some people, but in that case, my main thing was figuring out how to sell this product. Product changes were going to take 6-18 months, and we had not yet demonstrated that we had a viable offering. We hadn’t yet nailed it.

At another company I held a “strategy” role where I spent 60-hour weeks redesigning the product from the bottom up. That company had a killer sales and support engine, but we needed a next-generation product. The main thing was long-term product competitiveness.

In another case I was a classic marketer, and worked very closely with a killer marketing team. We had a great product and a good-enough sales team.

When I was working for someone else, I always liked to get involved in the company’s main area of need and found myself gravitating to different areas depending on that.

What is your company’s main thing? What one area, if improved, could make the biggest difference to the company? How can you get involved in that? It’s usually most rewarding to be involved in a company’s main thing.

Next question: “What is your own personal main thing?” How often do you ask yourself that? And how good a job are you doing of keeping your main thing front and center?

Since we are entering the summer months and a nice long weekend, allow me to suggest a little exercise:

Before you go on a significant vacation, make a to-do list for your professional and personal arenas. Don’t think too hard. Just write it down and seal it in an envelope.

When you get back, without looking at the other list, repeat the exercise.

When you get back from a significant break, I hope you will have recovered some sense of what the main thing is, for you as a person, for your career, and for your company.

– Alan

The Product Management Retrospective

You’ve just introduced your latest product release, introduced a new product or capability or launched the product. Now What? What about a retrospective? While product management and product marketing professionals often see engineering and development using retrospectives, how can you use this method to look back at what happened, while positively influencing the future?

What is a Retrospective?
A retrospective thrives in organizations using SCRUM methods and is a meeting where the team discusses the Sprint that just concluded and determines what could change that might improve the next Sprint.

In SCRUM terminology, anything that affects how the team builds software is open for debate. This could include processes, practices, communication, collaboration, environment, artifacts and tools. I believe and have experienced that a retrospective for product management and product marketing will provide clarity to future activities. Why?

Why a Retrospective?
Retrospectives bring insight and clarity. While it originated to bring development teams together, product management and product marketing need similar insight and collaborative review. While we have many one-on-one conversations and numerous meetings with stakeholders, product management and product marketing benefit from looking back to improve what’s ahead. Using retrospectives, product professionals will have insight into:

  • What’s happened and what’s currently happening?
  • What current activities have made the most impact?
  • What processes and best practices have worked and what needs improvement?
  • How is communication and what can be better?

Product Management and Product Marketing contribute and bring clarity to:

  • What’s changed or influencing our market?
  • What stories can you tell us that will validate where we are going?
  • What’s the competition doing and will it influence what’s planned?
  • Has anything shifted or influenced our strategy?
  • What’s the status of the product roadmap?
  • How are customer using our products and what have they experienced?
  • What’s been developed or delivered from the product marketing roadmap and how will it influence the channel?
  • What’s the timing or status of the next product launch?
  • How does our positioning resonate with customers and non-customers?
  • What has product management learned since our last retrospective?
  • What has product marketing experienced since we last met?

Implementing a Retrospective
At best, retrospectives are a great tool for infusing continuous improvement and collaboration, Depending on who you collaborate with most often, and the focus and role of your position, the following five areas should be considered when leading a retrospective.

  • Goals – in advance of the meeting, let everyone know about the focus of the retrospective, what you like to achieve and ask for input, topics and invite other to bring their accomplishments and war stories.
  • Set the Stage -let everyone know you’re hear to share, learn, listen and provide constructive feedback, as well as receive it. Look for ways to improve relationships.
  • Gather Data – before you get together, prepare current information and data that would be relevant. Ask other to share 2-3 minutes worth of information.
  • Generate Insight – with discussions flowing, start asking the why questions that will generate insight, support and consensus
  • Decide What to Do – while this isn’t a planning meeting, capture the information, validation and feedback. If you have access to a coach or facilitor, ask them to lead the session, so you can really engage and not worry about meeting management.

To stage better product delivery and introduction, I believe you should try a retrospective. If you’ve tried a retrospective, please share your experience. If you haven’t experienced a product management or product marketing led retrospective, give it a try and let us all know how it goes.

If you like the post, please share it via LinkedIn and Twitter – New post and idea, “the Product Management Retrospective” #prodmgmt #prodmktg #agile #leadership


Getting granular on WIIFM with psychographic segmentation

by Prabhakar Gopalan

Tweet this: @PGopalan: Getting granular on WIIFM #prodmgt #prodmktg

Why do marketing campaigns have poor conversion rates?  One answer to that question lies in getting to the right target group.  Here’s an idea to think about – get granular on your WIIFM and your conversion rates will dramatically improve.

If you are in marketing, you’ve probably been preached the mantra of WIIFM – ‘what’s in it for me?’ (‘me’ referring to your customer/sales prospect).  Most marketers get this.  You’ve also heard of addressing the WIIFM by talking about your product benefits to your customers versus listing features and functions.  Well, that’s nothing new and marketers get that too.  What then is missing or not working?  The answer lies in how granular you get in finding the WIIFM.

How do you normally do your segmentation analysis?  I speak with technology product marketers all the time and here’s what I find as the basis for most B2B marketing plans and marketing campaigns – segmentation of buyer groups by business size and geographies – just two variables, both of which give very little depth in understanding buyers.  The abstraction is so off the mark, you might as well do your marketing plan without those numbers.  This isn’t granular at all.

Psychographic behavioral segmentation

What’s granular is psychographic behavioral segmentation.  Psychographic behavioral segmentation is segmentation based on attitudes, values, lifestyle and behavior of the target group.  For instance, do all large enterprise buyers behave the same way in adopting a product or service?  How do their interests and opinions differ?  Can those be grouped in distinctive segments?  Do all small businesses have the same attitudes and values in using a product or service?  These are the kind of questions your segmentation sizing and analysis should answer.

A real life illustration

To illustrate how this works, I’ll give you a very simple personal example.  I had a recent project that involved conducting primary research on cloud computing.  I approached about 30 CEOs & CTOs combined, of local technology startups in Austin.  25 of the 30 I approached made themselves available for the project by being generous with their time for half a day.  While my study was about technology executives, narrowing it down to startup executives proved to be the reason for the high conversion rate of 83%.   What separates startup executives from large company executives is curiosity, a willingness to share and learn  – behavioral traits often missing in large company executives.  The startup execs WIIFMs were, in contrast to large company execs, about learning and sharing – a higher purpose.  Ultimately understanding these psychographic behavioral traits proved to be the reason for the high conversion rate in the study.

The next time you prepare your marketing plan or campaign, try something different – see if you can segment your buyer groups based on psychographic behavioral segmentation to get to the true WIIFM.

– Prabhakar

Tweet this: @PGopalan: Getting granular on WIIFM #prodmgt #prodmktg

Announcing ProductCamp Toronto 2011 – July 23

The next ProductCamp Toronto is set for Saturday July 23th at the Ted Rogers School of Management, Ryerson University, in downtown Toronto.

For those of you in the Toronto area, plan on attending. This will be the 4th ProductCamp here in the city.

For those of you unfamiliar with ProductCamp, it’s a collaborative, user-organized, unconference focused on education, networking and open discussion around product management, product marketing and related topics.

There is no cost to attend ProductCamp Toronto, but you need to register.

You can register here.

For more details, check out the ProductCamp Toronto site:

Looking forward to seeing you there.

Good Bye “Product Owner”, Hello “Backlog Manager”

by Saeed Khan

A few weeks back, I wrote a pair of posts about the title/role of Product Owner in Agile development environments:

In those two posts, I talked about some of the problems with the role and general definition of “Product Owner”, as well as the “scope creep” that seems to be occurring by Scrum advocates that give more and more “Product” responsibility to that role (e.g. budget, strategy etc.).  Aside from the clear overlap with Product Management responsibilties, the title is a misnomer: It’s really “project” focused and the “ownership” is really more about the stories and backlog, than the entire product.

In the first post, I suggested other titles for the role such as “Technical Product Manager”, “Backlog Manager” or “Project Owner”.

A comment from Rohan on that article suggested that the name “Product Owner” was too entrenched in the Agile community to have it “die” and so it would be better to try to contain the role vs. change it. At the time, I agreed with that thinking, and in my second post, focused more on the (re)definition of responsibilities as opposed to the title of the role.

Over the last several weeks, as I’ve thought about this more and done some additional reading, I decided that my original thrust — that both the name and responsibilities must change — was correct.

And with that, I’ve come to this post.

What does the “Product Owner” actually do?

The following are some descriptions of the responsibility of the Product Owner taken from Scrum focused sites on the Web.

The product owner is required to closely collaborate with the team on an ongoing basis and to guide and direct the team (e.g., by actively managing the product backlog, answering questions when they arise, providing feedback, and signing off work results.)

The Product Owner (typically someone from a Marketing role or a key user in internal development) prioritizes the Product Backlog.
(Source: Mountaingoat Software – a well known Scrum certification company)

The Product Owner represents the voice of the customer and is accountable for ensuring that the Team delivers value to the business. The Product Owner writes customer-centric items (typically user stories), prioritizes them, and adds them to the product backlog.
(Source: Wikipedia – Scrum Development)

Of course, there are lots of other sites to select from, but these three, all fairly reputable, generally agree on the focus of the “Product Owner”. The focus is on managing user stories, prioritization of those stories and assisting the Scrum team during sprints in answering questions etc. and ensuring the work done by the Scrum team is aligned with the business needs.  In short, it’s all about managing the backlog.

Welcome “Backlog Manager”

Whether it’s the product backlog or the sprint backlog; whether it’s prioritizing it, explaining it, pruning it etc, the focus of this role is to manage and oversee the backlog for the rest of the Scrum team and work with them as they implement it.

No, it’s not as sexy sounding as “Product Owner”. But as a ROLE, (as opposed to a title), it’s far more accurate and unambiguous. There’s a lot of work and responsibility (both explicit and implicit) related to managing the backlog. Work will not get done without someone actively working with “the business” to understand customer/market needs, and then working with the Scrum team to ensure those needs are met.

This is not a solitary role — the “Backlog Manager” is most likely part of a larger team — perhaps in Product Management (in an ISV) or a client facing team (in a consultancy).  Also keep in mind, that according to Scrum guidelines, there should be one “Backlog Manager” per Scrum team. i.e. for any sizable project or product – i.e. that has multiple Scrum teams — there will be multiple “Backlog Managers. In thinking about it, this makes a lot more sense than having multiple “Product Owners” — particularly when all the Scrum teams are working on a single product!

So, I’m sure there are detractors out there, but I’m casting a loud (and first vote), to change the name of “Product Owner” to “Backlog Manager”.  All those for? All those against?

Either way, I’d like to hear from you.


Tweet this: Good-bye “Product Owner”, Hello “Backlog Manager” – #prodmgmt #agile #scrum