Category Archives: Scrum

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.

Gilbert and Sullivan present: The High-Tech Product Manager

I’ve always liked the Major General’s song from The Pirates of Penzance.

Here’s how Gilbert and Sullivan *may* have described high-tech Product Managers.

I am the very model of a high-tech product manager,
I’ve information customer, partner and competitor.
I know the product roadmap and I wrote the full requirements,
From  strategic to tactical, all detailed in my documents.

I’m very well acquainted, too with matters very technical,
I understand development, agile, lean and waterfall.
On MRDs and PRDs I’m really eager to create
All the information that will make our products really great.

I am very good with customers and early stage prospects;
I listen to them carefully and track all of their change requests.
I then prioritize them into releases point and major;
I am the very model of a high-tech product manager.

I will answer all questions that will save an opportunity;
I really wish the reps would use a real sales methodology.
I always ask the prospects about the problems they must solve;
And then I’ll help the SEs create solutions that can evolve.

I bring this insight to HQ and deliver it accordingly;
I need the engineers to implement it all whole heartedly.
Then I can move along and start helping product marketing,
To understand the new solution and adjust positioning.

I define new offerings and also write the business case;
competitively speaking, I’m not satisfied with second place.
In short, in matters customer, partner and competitor,
I am the very model of a high-tech product manager

I  have worked in other jobs as a sales rep and a marketer;
I even spent two long years as a database developer.
But I would wonder constantly what kind of role  was best for me;
I thought and thought and talk to others,  then I found some clarity.
I really am a business person, with fondness for technology
I blend it all together to create great product strategy

I think Product Manager was the job that was meant for me.
Yet I wonder if others think I’m easy going or cranky?
I only hope  the role will grow real soon into maturity.
But still in matters customer, partner and competitor
I am the very model of a high-tech Product Manager.

And here are two versions of the song. The original, and  my favourite spoof of the original.




Related Posts

The Software Product Management Blues

The 12 Days after GA

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.


A 5th element for the Agile Manifesto

Robert Martin gave a keynote at the Agile 2008 conference. Entitled Quintessence, he talked about adding a 5th element to the Agile Manifesto. His suggestion was:

Craftsmanship over Crap

After discussion and thought, he later proposed a refined version:

Craftsmanship over Execution

This is meant to focus developers on writing good code vs. simply writing code that works. Both craftsmanship and execution are good things, but taking care to write good code is viewed as more important.

The attitude is described in the Principles behind the Agile Manifesto, but is not explicitly listed as one of the elements of the Manifesto itself.

Continuous attention to technical excellence and good design enhances agility.

But few people seem to think about those principles explicitly. The focus of many agilists is specifically on the 4 elements of the Manifesto itself.

But, is this really a principle that needs to be enshrined in the Manifesto? Shouldn’t everyone (ideally) take care of the details and be diligent in their jobs?

In my opinion, looking at the the Agile Manifesto:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

I don’t think it’s sufficient to be added to the list. Don’t get me wrong, I agree with the call for people to do good work, but to me that should be a given. The beauty of the manifesto is that it is concise. Each element is clearly distinct from the others and espouses a different aspect for the profession: people, code, customers and agility.

What’s missing from the Manifesto?
But there is something that is missing from the Manifesto. Most software is written for business purposes. It could be an internal IT team or an ISV, or part of some other technical product that will be brought to market. This context needs to be in the mind of development and QA teams as they produce and test code. And as they make decisions on what to do and when, they need to decide if it is important for the business or not. And if they don’t know whether something is important, they need to know enough to ask.

I propose the following as the 5th element of the Agile Manifesto:

Business alignment over engineering efficiency

Why? Because as trade-offs are made, as test cases are created, and bugs and issues are prioritized, the overall business context must be kept in mind.

No set of requirements will provide every constraint that needs to be taken into account. No set of user stories will be perfect, regardless of how intimate the Product Owner is with customer and market needs. No individual can tell the testers the best combination of tests that need to be run.

The focus of Agile is on “individuals and interactions”, and those individuals need to be empowered to make appropriate decisions. But, without the proper business context, they will not be able to optimize what they do.

Have you ever had software that couldn’t install properly? Or had licensing problems? Or found certain design decisions prevented the product from easily being OEMed by partners? Or had APIs in the product that were only usable by the developers who wrote those APIs? Or had user interfaces (radio buttons, check boxes, drop downs etc.) that functioned more like a developer’s logic path than a user’s intended workflow? These are are all cases where the business context was not kept in mind.

I once saw the following happen with a software product. A customer had purchased the product and licensed some modules. When they installed the product, the license keys for at least one module didn’t work. The module’s functionality couldn’t be enabled. The Support team identified it as a bug in the licensing functionality and escalated it to Product Management.

The PM went to the head of QA to find out more about the problem. The conversation went something like this:

PM: Hey, just wanted to confirm whether this bug with licensing is really a bug?

QA: Yes it’s a bug.

PM: Then it’s a regression right, because I know the licensing worked in the previous release.

QA: Yes, it’s a regression.

PM: So, how did we miss this? Who tested the licensing?

QA: [Looking at the PM more intently] No one tested licensing.

PM: Uhhh…what do you mean by “No one tested licensing.”

QA: Licensing wasn’t tested because there were no licensing changes between releases. We have to prioritize the work we do. We can’t test everything. What do you expect? Zero bugs? That’s never going to happen.

PM: Agreed, you can’t test everything. And I don’t expect zero bugs? What do I expect is zero surprises and licensing that actually works. Licensing is how we make money. It has to work or there is no business.

QA: Look, there will be a patch out tomorrow. And as I said, we can’t test everything. We didn’t test licensing. And I’ll tell you, if my boss was here right now, he’d support me in my decision.

PM: I have my doubts about that.

It turned out (thankfully) that the QA Manager’s boss didn’t agree with him. But, the QA head was not a junior guy. He’d worked in software for about 10 years. Yet he didn’t understand how important licensing was to the business. From his perspective, it was no different than any other “feature”.

I’ve seen this kind of thing many times from Engineering teams. It’s not just applicable to licensing. For example, when they promote the creation of SDKs and APIs when end-user functionality is what is required, or advocate for “rearchitecture” or “refactoring of code”, when neither provides any clear business benefit.

This kind of thinking has to be rooted out of the culture of software development. Other groups such as sales and marketing, albeit because they are close to the business side of things, better understand how to prioritize business needs. Software development needs to line itself up as well

We want efficient engineering teams. They should not be wasting cycles on non-productive work or work that has little value. But, that drive towards efficiency, velocity and productivity cannot be blind to the priorities and needs of the business. Those business priorities must be incorporated into the day-to-day decision making that takes place in a product development cycle.

When all teams in the company from Product Management, Sales, Marketing, Operations AND Engineering understand and embody the needs of the business, as often happens in the tightly-knit teams of a startup, the business can truly deliver on it’s promise and potential.

Do you agree/disagree? Would love to hear from you.


Is Product Management Agile?

There’s a lot of talk about Agile Product Management these days, and for obvious reasons. The thinking is that because of Agile development, Product Managers need to change how they function and adapt themselves to a new way of developing software and become “agile”.

But the reality is, Product Managers have always been agile, and finally the software developers are coming around to OUR way of thinking!

Yes, you read that right. Agile is the result of engineers finally understanding what’s really important and making a bold declaration that they now understand. But of course, being engineers, they won’t give credit to Product Management. They’re taking all the credit themselves for this tremendous insight and seachange in their profession. 🙂

Don’t believe me? I’ll prove that Product Management has always been “agile” using the Agile Manifesto itself.

The Manifesto has 4 elements. They are:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

OK. Let’s take one at a time and apply them to Product Management.

Individuals and interactions over processes and tools

Most product management teams are understaffed. In fact, in many companies you’ll only find individual product managers working alone with teams of developers. They have no choice but to interact face-to-face. And not just with Development, but with every other group in the company and many parties outside of the company.

“Hub of the wheel”? You know what that translates to in the real world? Meetings, and lots of them, with the primary objective to keep all teams aligned and aware of progress, status and plans. Those cross-team meetings aren’t for the benefit of Product Management!

As for processes and tools…well, most PMs will tell you they do what it takes to get the job done, and the only tools they have are usually email, Excel, PowerPoint and Word, possibly some crappy (free) wiki software and Post-it notes. No fancy (or even basic) requirements management tools for most Product Managers. Individuals and interactions: Yes. Processes and tools: Not much. Score: 1 for 1.

Working software over comprehensive documentation

What PM doesn’t want working software? If only the final product that came out of Dev and QA was guaranteed to always work as expected. PMs want working software so much they perform QA, file bugs, run beta programs and hound the testing teams to ensure all the important use cases actually work.

How many times have we taken a pre-release build and found that it doesn’t install properly, or fails when upgrading from a previous version, or has licensing problems or runs really slowly using real world data sets. Ensuring working software gets out the door is top of mind for every PM, and even though helping QA the product is not technically part of our job, many of us do it anyway to raise the probability of actually delivering working software.

Regarding comprehensive documentation, we don’t tell Dev teams to create 50 page spec documents. They choose to write them and then PMs are forced to sit through endless “spec review” meetings to ensure Dev has taken the requirements and translated them properly into something THEY understand.

As for creating comprehensive documentation, PMs can never be accused of that. What’s the most common complaint from Engineering about Product Management? Answer: “The requirements aren’t detailed enough.” ‘Nuff said. Score: 2 for 2.

Customer collaboration over contract negotiation

Too easy. Really, do I have to explain this one? OK, I will. “Product Management: Voice of the Customer”. How often have you heard that phrase? Meaningful phrase or not, Product Management focuses extensively on customer insight and collaboration. It’s another core aspect of the job.

But, there are countless true stories of Engineering VPs who exhibited disdain for what customers actually want or need. These people are so smart they know what customers need, with little if any input from the customers themselves. Case in point.

A survey of 500 customers showed clear priorities for a number of big ticket items that needed to be added to a product. Capability <A> was ranked #15 by customers but was a pet project of the VP Eng. Capability <B> was ranked #2 by customers. We only had the resources to do one of those 2 items, along with everything else that was planned.

PM: We’ve laid out the requirements in priority order. < B> is critical for the next release and given the target release date, resources and survey results, we’ve deprioritized <A>.
VP: Hold it a minute. Are you saying that <A>  is not important?
PM: Well, it’s not as important as <B> and the other things we’ve prioritized for this release.
VP: I was talking to MegaBankCorp last week, and they really emphasized the need for <A>.
PM: Yes, I spoke to them too. But they’re one of only 3 companies who have indicated they have an urgent need for <A>. I’ve got 50 companies that need <B>. <B> is more important than <A>.
VP: I don’t think you’re talking to the right people. I hear people asking for <A> all the time. Our major competitor has <A>, and we’ve lost deals to them.
PM: We’ve lost 1 deal to them on <A>, The sales team agrees that <B> is much higher priority than <A>, and the 500 hundred customers I surveyed agree as well.
VP: Don’t you realize <A> is strategic? Don’t you even read the industry news? You know what the problem with Product Management is?
PM: I’m sure you’re going to tell me.
VP: You talk to too many customers! You don’t talk to enough people who don’t use our product.
PM: People who don’t use our product also don’t tell us what they want added to the product. But, if you have the resources to do both <A> and <B> in this release, then be my guest. But <B> is top priority if you can’t do both.

Result: VP storms out of the meeting. Sends and email the next day indicating that after analyzing the effort and resources, both are not possible in the coming release so only <B> can be done.

Of course, not all Dev leads and VPs are as stubborn. But when it comes to wanting to work with customers, as opposed to sitting in meetings trying to get Engineering to buy-in on what is needed, Product Managers have always advocated for that. Score: 3 for 3.

Responding to change over following a plan

Next to “The requirements aren’t detailed enough“, the most common complaint that Engineers have of Product Management is that PMs regularly “change their mind“. Most PMs don’t simply change their mind about things, but reprioritize what is important based on new data, new market conditions or other external changes that take place. That’s core to the role of Product Management. The world is a dynamic place, and when your competitor is bought out by and industry giant, or you find that you’re losing deals because of product gaps, action must be taken.

Yes, there are some flaky PMs who don’t have a clue about things, but that can’t be helped. Most capable PMs are reasonable people who need to focus on the business and leverage the engineering resources to help drive business benefit. It’s hard enough to predict what will happen 3 months from now, let alone 12 months from now.

But if a development cycle will take 12 months to complete, Product Management must be collecting the data to define that release many months in advance. Hey, we’re smart, but we’re not the Oracle of Delphi. We make decisions. Decisions are based on the information we have today. If something material happens after a decision is made that requires a change in product plans, the change must be made. Product Management always understood that. Engineering seems to be finally realizing that. Score: 4 for 4.


So there you have it. QED — quod erat demonstrandum.

Product Managers have been living, breathing and advocating the elements of the Agile Manifesto for years before the Manifesto was even a firing synapse in the brains of any of it’s authors. Developers though were set in their ways, pushing back on Product Management for changing priorities, not providing enough detail in requirements etc.

I’m glad, even if they don’t want to admit it publicly, that Engineers are finally seeing the light. Now, if we could only get Management to allocate more headcount to Product Management, life would almost be perfect.