Category Archives: Agile Development

Guest Post: There’s no such thing as MEDIUM

Add to FacebookAdd to DiggAdd to Del.icio.usAdd to StumbleuponAdd to RedditAdd to BlinklistAdd to TwitterAdd to TechnoratiAdd to FurlAdd to Newsvine

NOTE: The following is a guest post by Tzvika Barenholz, a Product Manager living and working in Israel. If you feel inspired to write a guest post of your own, click here to find out how to submit it to us.

We all know the situation: you’ve collected a bunch of product requirements, put them into a nice excel sheet or clever table-like GUI front-end; you’re all psyched about making the big decisions, prioritizing and leading the product to the proverbial “next level”. You sit in front of the screen, crack your fingers, stretch a bit and place your hands in the typing position.

“First item, feature xyz” – yes, you say it out loud, you’re psyched remember? – “First column, Importance” (or priority, or appeal, or whatever is your favorite alias for customer value)

OK – now what *was* the priority of feature xyz?

Let’s see. A couple of big customers have asked about it in a recent expo, so probably high, right? Then again, it’s one of those things that make the product more complicated, so call it low. Having said that, it would really improve average sale price, which is aligned with the five year plan, so high it must be. But what about breadth? It really would only appeal to a fraction of our customers. Back to low again.

And on, and on.

Exasperated, you note that after 20 minutes you’re still on item #1 out of 37. It’s looking more and more like a long night of pizza and coke with the developers. The next thing you know, there’s a little voice inside your head that whispers: make it a medium!

Of course! How foolish you’ve been to overlook this possibility before. A medium is right in the middle between high and low. It’s the perfect answer for what seems to be neither here nor there, or both here and there. Your right index finger then makes it merry way to the m key.

But STOP – you’re just a moment away from falling into a trap as old as the hills. Why? Because there is absolutely positively no such thing as a medium, except maybe as a shirt size.

“Medium” is a shirt size, not a useful priority rating

Prioritizing something as medium is just a way chickening out of making a decision. If you don’t have enough information to make the call, go get the information, then make the call. If you’re piling up different qualities like “broad appeal”, “helps sales”, “improves margins” and “technologically strategic”, then by all means, add 4 columns, fill them out with highs and lows (or yes or no, for the more advanced practitioners who know how to make an even cleaner cut), and then rebuild the priority column as an index composed of them all.

But whatever you do, don’t just cop out. Don’t just type medium and move on to the next item, or you will end up building the wrong things for the wrong reasons.


Upcoming ProductCamps

Add to FacebookAdd to DiggAdd to Del.icio.usAdd to StumbleuponAdd to RedditAdd to BlinklistAdd to TwitterAdd to TechnoratiAdd to FurlAdd to Newsvine

ProductCamp New York was last weekend and it appears to have been quite successful. Alan attended and wrote up this post about it.

If you missed the New York session and want another chance to attend one, there are 4 5 more in the works in the coming months, starting with ProductCamp Austin in only a few weeks.

ProductCamp Austin
Date: Saturday August 15, 2009
Location: The University of Texas at Austin, McCombs School of Business, Austin
More details: click here.

Followed by one in September.

ProductCamp RTP2
Date: Saturday September 26, 2009
Location: Cambria Suites, Raleigh-Durham Airport
More details. click here.

And 2 ProductCamps in October.

ProductCamp Toronto 2009
Date: Sunday October 4, 2009
Location: Ted Rogers School of Business @ Ryerson University
More details: click here.

ProductCamp Seattle
Date: Saturday October 10, 2009
Location: Amdocs, 2211 Elliott Ave, Seattle WA
More details: click here.

And to round the year off, Boston is holding their camp in November.

ProductCamp Boston
Date: November 7, 2009
Location: Microsoft New England R&D Center, Boston MA
More details: click here.

For information on these events as well as other events relevant to the Product Management, Product Marketing and Product Development communities, check out our Events page. And if you know of an event we should list, let us know in the comments of that page.


Guest Post: Triangle Offense and Scrum Mania

Add to FacebookAdd to DiggAdd to Del.icio.usAdd to StumbleuponAdd to RedditAdd to BlinklistAdd to TwitterAdd to TechnoratiAdd to FurlAdd to Newsvine

NOTE: The following is a guest post by anonymous blogger GeekMBA360, author of the blog by the same name.  If you feel inspired to write a guest post of your own, click here to find out how to submit it to us.

– – – – – – – – – – – – –

Phil Jackson has won more NBA championships than any other coach in history. He won six championships with the Chicago Bulls, and then won another four championships with the Los Angeles Lakers.

If you’re a basketball fan like myself, you probably know that Phil Jackson utilizes a unique offensive system called the Triangle Offense.

The Triangle Offense has been around for a long time. According to Wikipedia:

“the triangle offense’s most important feature is the sideline triangle created between the center, who stands at the low post; the forward, at the wing, and the guard at the corner. The team’s other guard stands at the top of the key and the weak-side forward is on the weak-side high post — together forming the “two-man game”.

The goal of the offense is to fill those five spots, which creates good spacing between players and allows each one to pass to four teammates. Every pass and cut has a purpose and everything is dictated by the defense.”

I’d like to make a few observations about Phil Jackson’s success and his use of the Triangle Offense.

First, Triangle Offense is neither sufficient nor necessary for winning a championship. It’s true that both the Chicago Bulls and Los Angeles Lakers had great successes with the system. However, there are also many other teams who had been very successful by employing other offensive systems.

For example, the San Antonio Spurs has won four championships between 1999 and 2007 (the most in the NBA during that period) by having a totally different system. Other championship teams such as the Detroit Pistons and Houston Rocket also had very different offensive systems.

A good team implements whatever system fits it the best. It doesn’t try to impose a system on a group of players.

Second, triangle offense requires the right combination of players. Because it is such a fluid system, it requires the players to be very flexible. For example, the systems prefers a big-man center who can pass the ball well, and a small forward who can defend and shoot the 3-pointer. It’s a complex system. The players must have the patience to learn and practice in order to play effectively in the system.

It’s not a system that could be retrofitted to any team. Some players are simply not good fit for the system.

Third, Triangle Offense requires an excellent personnel manager and a solid X’s & O’s guy. According to this ESPN article:

“Being a great NBA coach is about managing egos, earning your players’ respect, developing team chemistry, making (in-game and off-day) adjustments, and emphasizing the right things. And no one’s ever done all that better than Jackson.”

Phil Jackson has Tex Winter as his assistant coach. Tex Winter literally wrote the textbook on triangle offense, and is an expert in teaching the X’s and O’s of Triangle Offense. Clearly having the right supporting cast is incredibly important.

The relationship to Product Management

Now, let’s move to our professional world of product management and software development.

In the past few years, I think our industry has had a “Scrum mania” — there are armies of consultants and trainers who tout the merits of the Scrum methodology. Company executives send people to get “Scrum Master” training and assume that their products would be shipped on-time.

An example from real life

I worked for a start-up company that provided a hosted data mining product. It had about 30 clients. Each client had a separate instance of the application.

Because of the amount of customization for each client and complexity of the software, it would take a couple of weeks to deploy a new version of the software since the new software had to be tested for each client. The deployment process was a little bit different for each client due to customized settings and configurations.

The development team had been doing a good job. But, one day, the big boss attended a seminar on Scrum. He wanted the company to adopt Scrum methodology. He sent two Program Managers to get certified.

He even brought in a trainer to give all of the developers a one-day Scrum training session. His rationale is that instead of shipping a new release every three months, we’ll get something done and ship product every month.

It was a disaster.

Most developers on the team used to work for large packaged software companies such as Microsoft, Oracle, etc. They were excellent developers who were used to the waterfall development model. And most of them had been working at this start-up for a long time.

They rebelled against the Scrum process. Instead of daily Scrum updates, they’d much prefered spending the time on design and coding. They also hated to update their tasks using the Scrum software.

Because of the complexity of the software, each developer got very little done during each 3-week scrum cycle. And then they have to attend another several hours of scrum planning. It became very inefficient.

The morale was low. Scrum Masters and developers spent hours debating the right way to do Scrum during each Scrum planning session.

You could argue that this company implemented Scrum incorrectly. There is nothing wrong with Scrum itself.

However, I think this is an example of a company that probably should not have implemented Scrum at first place. Just like the Triangle Offense, Scrum is a methodology, a system.

Scrum is neither sufficient nor necessary for running successful software projects.

Scrum requires the right combination of personnel: Developers must buy into the new systems, and be willing to adapt. In this example, the company had a group of very experienced, senior developers who were used to a waterfall development model that had worked well in the past. It was very hard to get their buy-ins, especially given the nature of the products they were building.

Running successful Scrum requires a excellent personnel manager and a solid X’s & O’s guy. In this particular company, the Scrum Masters were well trained. However, the development manager and senior management team didn’t fully understand the cultural and organizational challenges of implementing a new system. And this was what led to the downfall.

Are you thinking about putting a new system in place? Think and plan carefully. You want to put in the best system for your organization. Simply adopting systems used by other organizations won’t work.

GeekMBA360 is a product management executive with over a decade of experience in e-commerce, online advertising and enterprise software. His blog,, offers career insights at the intersection of business and technology. He also publishes the popular Great Depression 2.0 Survival Guide for High Tech Professionals.

Happy (belated) birthday to us (again)!

Add to FacebookAdd to DiggAdd to Del.icio.usAdd to StumbleuponAdd to RedditAdd to BlinklistAdd to TwitterAdd to TechnoratiAdd to FurlAdd to Newsvine

Well, just like last year, we did it again and forgot our own birthday.

It was June 1, 2007 that the first item was posted on this blog. Now, two years and 280+ posts later, life on the blog is thriving. That’s about 1 blog post every 2 1/2 days for the past 2 years!

I’ve met a number of really great people through this blog — other bloggers as well as readers. It still amazes me when I go somewhere and meet someone who recognizes my name from the blog.

Here are some highlights from the past couple of years. We wrote a several series of articles on:

How to be a Great Product Manager

Conducting Win/Loss Analysis

Discussing Social Media

  • The Lowdown on Social Media Parts 1, 2 , 3 and 4

Contrasting Product Managers with Product Management

  • Product Manager vs. Product Management Parts 1, 2, 3, 4, 5, 6

We were nominated for awards…

But we didn’t win anything 😦

A simple post on an uninterruptible power supply…

Became an important lesson for APC on the perils of social media

There was a LOT of talk about Agile/Scrum this past year

We held our first ProductCamp here in Toronto

We (macro)blogged about Twitter

We Discussed Organizational Structures

And US Politics

We oversaw a few kerfuffles

Wrote some Haiku

Parodied some songs

And had some sympathy for the Devil’s Dictionary

It’s been a good couple of years. Thanks to the ever growing audience to this blog for reading and commenting, and soon guest blogging.

Maybe next year, we’ll remember June 1 as the anniversary. Here’s to another 140 posts for the next 12 months.


Adam Bullied vs. Enthiosys: Don’t Fight!

Adam Bullied has a post last week entitled “Are agile PMs baloney?

First off, great title. No burying the lead here. You can read the post on Adam’s site, here’s the key point he makes:

My belief has always been, product management doesn’t change that much regardless of whether you are in tech (B2B or B2C), consumer products (like soap or fabric softener), cars, electronics, etc… Essentially it all boils down to the exact same things: you have a market, and they have a problem. You are charged with crafting the most ideal way to solve that problem, and then making that vision a reality.

Regardless of HOW those charged with executing that vision (or building the requirements) choose to do that, your paradigm doesn’t change. Developers can be working in waterfall, or they can be working in agile. You, as a product manager, shouldn’t care.

This is really interesting, as I wrote the following in one of my first posts on Agile:

Keep in mind, Agile/Scrum is a DEVELOPMENT methodology. It is a great model for developers and engineers and other R&D team members to work and communicate more efficiently. There are very clear benefits to this model. It provides greater visibility into current work status, work remaining, can identify development hurdles earlier and can communicate them outward more easily.

But, in the end, it is still a development methodology. It should have minimal impact on Product Management’s job as a cross-functional leader marshaling the product from development through marketing, sales etc.

Now the remarkable thing about Adam’s post was the sheer number of comments generated; almost as many as a Failblog post! There was also a lot of passion evident in many of the comments. I even got into the act with a few choice comments myself!  (here and here).

But not everyone agreed.

A shot across the bow?

Shortly thereafter, the folks at Enthiosys posted an article on their blog entitled: How To Sound Smart (But Be Really Naive) About Dramatic Changes in Technology

I know both Adam and the team at Enthiosys personally. I like  and respect them all,  but I’m going to have to take sides here, as this issue of Agile (or agile) and Product Management is something that I’ve blogged on quite extensively.

First off, the title of the Enthiosys post comes across like an ad hominem attack on Adam. Maybe it wasn’t meant that way but it sure sounded like it to me.

The author of the post states:

I’d reframe his question (“Are agile PMs Baloney?”) into something meatier: “Do radically different ways of building software radically change how software product managers do their job, and how does this change our thinking about delivering value to the market?”

So, that’s actually a very different and rather pointed question, not simply reframing the original question.

I also think that the reframed question implicitly pigeonholes the focus of product management into something far less than it actually is.

Let’s start with an analogy

The Enthiosys post continues with the following example:

Suppose I was an industrial designer working in the early 1950’s. My job? Creating new tools for machine shops. My tools? Pencil and paper. Clay and wood prototypes. My development process? Relatively slow. Feedback loops? Long. To compensate, I work as much experimentation into my process as I could, but, let’s face it: there was only so much experimentation that I could try.

Fast forward to today. I’m still an industrial designer making tools for machine shops. Except now I’m not using pencil and paper, I’m using a sophisticated CAD-CAM system. I might be using wood and clay, but chances are good that I’m printing my prototypes. My development process? Fast. Feedback loops? Short. My ability to experiment with alternatives, and to use experiments with customers, is so easy that I find myself naturally collaborating throughout my process.

Now, ask yourself: Has the job of the industrial designer changed?

My response…Darayush’s words

First an answer to the question. I’ll quote from one of the comments on the Enthiosys post left by Darayush Mistry:

The job of an industrial engineer hasn’t changed. The tools have. An industrial engineer with good fundamental skills would be just as effective in the 1950’s as today. A good cook will be just as effective regardless of the tools, cause cooking is all about understand the fundamentals of how ingredients mix/blend/cook at various temperatures rather than the hi-tech gas range and ovens.

I fully agree with Darayush on this point.

My response…my words

Second, the analogy of the industrial designer is not a good one. The difference between Agile development and previous development methods and their relationship to Product Management is not the same as the difference between pen/paper/wood/clay and CAD/CAM systems and the relationship to an industrial engineer.

Why? The industrial engineer is NOT analogous to a product manager. The engineer will build a prototype or tool based on requirements or specifications provided to him/her. Someone had to decide and define what new tools were needed, what purpose they’d serve etc. If it was the industrial engineer, he/she would have done this BEFORE creating anything in pen/paper/wood/clay or using CAD/CAM.

Once the engineer has those requirements or specifications, they can certainly create prototypes and designs faster with CAD/CAM tools, but at that point, they’re functioning in a role more like a product designer or a developer.

Third, and I think this is really important, the product management relationship with product development is only one aspect of the role. Product Managers must be focused on the business success of their product, not simply the “manufacturing” of it.

Finally, I think it’s very important that Product Managers in the high-tech community understand that they have a critical business role to play in the success of their companies. There are a lot of obstacles in the paths of these Product Managers.  The profession is still young and not well understood. There are few if any good preparatory programs to equip Product Managers with the tools and skill sets they need to be successful. Power politics in companies weigh heavily on the success of Product Managers. With these and other obstacles in the way, the last thing Product Managers should be doing is attaching potentially confusing or misleading terms such as “agile” or “Agile” to themselves.

What happens a few years from now when the focus on “Agile/agile” diminishes in the Development community? What happens when the next new and innovative and hyper-efficient software development model comes out? Will a new adjective need to be attached to the title “Product Manager”?

And finally…really!

Product Management needs to be defined on it’s own terms. We as a community need to take that responsibility on ourselves. Tying our profession to what is fundamentally a software development methodology, no matter how potentially applicable it’s core principles may be to other domains, is not the right thing to do. It will not bring clarity of the purpose and full value of Product Management to others.

I argue (quite successfully I must say :-)) in this post, that Product Management has always been agile and that it is Development that is finally understanding the value of being nimble, adaptable to change, not tied into rigid methodologies etc. The Agile Manifesto was a call for change in the Software Development community, not the Product Management community.  Let’s keep that clearly in mind.


Towards a Product Management Manifesto (part 1)

manifestologoredsmallYes, this is going to be a multi-parter. It’s a big topic and it makes sense to discuss it in steps.

I’ve been thinking about this topic a lot, and several posts recently by Brian Lawley at the 280 Group,  Tom Grant at Forrester, Steve Johnson at Pragmatic and finally one by the folks at Brainmates convinced me that the topic was ripe for discussion.

While I’m sure the topic has been informally discussed by many previously, the first formal written piece I saw was last summer. In a post entitled “The Product Management Manifesto“, Adam Bullied takes an initial stab at defining some key principles for Product Managers to follow:

  • Understand the problem
  • Know who it’s for
  • Ascertain appropriateness or health
  • Develop a clear picture of the future
  • Execute in concert
  • Shepard and adapt based on feedback

He also states the need for more good books on the subject and more formal education. He even created a wiki site: for people to contribute to. All good stuff, but 7 months later we’re no closer to addressing the problem than we were in June.

What are we talking about?

Before getting to the problem, I want to make sure the context of this discussion is clear. While we consider ourselves Product Managers, it’s important to specify that we are technology Product Managers or even more specifically for many of us, software Product Managers.

Product Management, which originated  in the Consumer Packaged Goods (CPG) industry, is very well defined. I’ve written about some of the differences between Product (or Brand) Management in CPG companies and analogous roles in hi-tech companies here.

A bit of history

Back in the 1930s, a manager at P&G named Neil McElroy wrote what is now referred to as the McElroy Memo. He was a manager responsible for Camay soap — a lesser brand to the company’s leading Ivory soap brand. Camay was not selling well and he decided that a dedicated “brand man” was needed to ensure that sales of the brand were being maximized.  Here’s a good post that lists the text of that original memo.

After almost 80 years, Brand Management is well defined and is a pure marketing and business function within CPG companies. High tech, or software product management is much much younger. The origins of it can be found in an article in the Harvard Business Review in 1991, written by Regis McKenna. I’ve blogged about that article here.

In short, McKenna stated that technology is changing the traditional push marketing and selling model into one that requires insight and understanding of customer needs and wants:

Technology is transforming choice, and choice is transforming the marketplace. As a result, we are witnessing the emergence of a new marketing paradigm– not a “do more” marketing that simply turns up the volume on the sales spiels of the past, but a knowledge- and experience-based marketing that represents the once-and-for-all death of the salesman.

This is why I blogged on the article. To me it represented the birth of our field: technology product management.

What is a manifesto?

Now, let’s talk about manifestos. A manifesto is a public declaration of principle or intent. While usually political — the Communist Manifesto and the US Declaration of Independence being two of the most famous examples — they can be on any topic.

There have been quite a few business oriented manifestos in recent years including the well known Agile Manifesto, the Incomplete Manifesto, the Cluetrain Manifesto and the more recent Peanut Butter Manifesto from an SVP in Yahoo. A large list of manifestos, old and new, can be found at  My recent blog post about a 40year old print ad entitled “Do this or die” talks about that ad being a manifesto.

While manifestos are defined as public declarations, they are created when people see large problems that need group action to be corrected. And if that change doesn’t happen, the creators of the manifesto predict big trouble for their audience.

The Agile Manifesto was a call for change in the practices, attitude and culture of software development. The Peanut Butter Manifesto was a call for change in how Yahoo! was run as a business. The “Do this or die!” print ad was a call for change in how advertisers treated their markets and customers.

The creators of all of these manifestos saw problems around them, close the them, that troubled them, and decided to speak out and start the process of change.

And change is really what people are after when they create a manifesto: a better country, a better life, a better profession, a better industry etc.

But keep in mind that change is a process, not an event!

Creating a manifesto and publicly declaring it means nothing. It’s only when the principles and positions defined in the manifesto are enacted does the change happen. The Agile Manifesto was created in February 2001. And it is only now, 7 or 8 years later that significant change is happening based on that declaration.

Does Technology Product Management need a manifesto?

Hmmm…I can’t speak for everyone, but I wouldn’t be writing this series of articles if I didn’t think so. 🙂

I do think there are problems within technology product management that need to be addressed. Likely over time, many of them will be addressed as both the technology industry as well as technology product management mature. But who knows how long that will take and in what direction it will go?

We need to be masters of our own domain. If we want to see positive change in our profession then who else will speak for us and define what that change needs to be?

And being that we are product managers, who (amongst many other things) focus on understanding problems and identifying clear requirements to address those problems, shouldn’t addressing our own problems be at the top of our priority list?

In the next installment, I’ll talk about something we all know and love:  problem statements and requirements.

In the meantime, please let me know your thoughts on this topic. What problems (if any) do you see or are you experiencing as a technology product manager or product marketer? And what ideas do you have on how to address them?


Related Posts:
Towards a Product Management Manifesto (part 1.5)

The Agile Disease…

Having written a fair bit recently about Agile/Scrum, I found the following post provided an interesting perspective.

The Agile Disease by Luke Halliwell

I don’t agree with everything the Luke wrote, but a lot of his points make sense.

A lot of the benefit of Scrum is handled if people simply use common sense with whatever process they use. I’m happy to say that at my current company, we just put out a major release of our product, included a lot new functionality and platform support, as well as renamed, rebranded and repackaged how we will sell the product, all in a 4 1/2 month development and test cycle, and all WITHOUT using Agile.

That team will be moving to Scrum very soon (corporate mandate), and I’m interested in seeing what, if any, efficiencies they’ll gain. I think the best way to make that team more effective is give them more developers. 🙂 We have a big backlog!

The one point that Luke made that particularly caught my eye — and I’m surprised I didn’t realize it before is the following:

“Individuals and interactions over processes and tools” I couldn’t agree more with, but strangely, Agile is all about following processes and rarely mentions that having top people is the best thing you can ever do for a project (you could say your hiring process is more important than your development process!).

The irony of the first element of the Agile Manifesto and the fact that Scrum imposes quite a bit of process on people — Scrum Master, Product Owner, backlog management, daily standup etc. — should be noted.