Month: October 2008
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.
By Saeed Khan
The confusion seems to come from the focus of Scrum on short development cycles and the ongoing prioritization and reprioritization of needed functionality in the Product Backlog.
So, is there a conflict here that would prevent or hamper the creation and maintenance of product roadmaps in an Agile environment?
The answer is absolutely not. In short, Scrum is a development methodology, and roadmaps are business planning and communication tools. The two are independent of one another and there should be little impact on maintaining a product roadmap in any company where Engineering adopts Scrum.
Not satisfied? OK, here’s a slightly more detailed answer.
First, let’s agree on what a product roadmap is NOT.
It is NOT a 100% guaranteed, take it to the bank (ok, not all banks these days) definitive and unswerving description of what will absolutely be built in the next several releases of a given product.
No, that is not what a product roadmap is. Even though, that is what a lot of salespeople will want and demand it to be.
|BTW, as an aside, here’s a little trick on how to handle salespeople who demand an absolutely fixed, definitive roadmap for the future. Tell them, Product Management will commit to such a roadmap, when the sales team commits to an absolutely fixed, definitive sales number for the next 4 quarters. Watch their reaction. I doubt you’ll have any takers.|
So, what is a Product Roadmap?
A roadmap is a planned future, laid out in broad strokes — i.e. planned or proposed product releases, listing high level functionality or release themes, laid out in rough timeframes — usually the target calendar or fiscal quarter — for a period usually extending for 2 or 3 significant feature releases into the future.
For startups or companies in fast moving and growing markets, those 2-3 releases might only cover the next 12 months of time. For other more mature companies in less dynamic markets, those releases might cover several years.
I emphasized the word “planned” above. Plans are simply plans. They are our intentions for the future given what we know and believe today. They are not commitments. Most roadmap presentations I’ve seen, and virtually every single one I’ve seen from a public company starts with a big disclaimer that absolves the company from committing to anything that is presented in the roadmap.
And, people listening to the roadmap take it in stride. They understand that the future is not certain. What they want to hear is a statement of intent, that is credible and potentially achievable, and that can help them make plans for their own futures.
Note that none of this has anything to do with what kind of development methodology is used to potentially implement the planned functionality. And if anyone does ask, a great answer might sound something like this:
Our development teams use a hybrid approach that leverages the best of current Agile methodologies, mixed with the more predictable and steadfast aspects of waterfall. This gives us the flexibility we need to adapt to changing market conditions and customers needs, but still maintain a rock-solid foundation in our development cycles that enables us to continue to deliver high quality releases year after year.
If nothing else, people will nod their heads in agreement and never again ask about your development methodology.
Finally, most product roadmaps are so devoid of useful information that they are simply a set of talking points or a listing of product release codenames on a single slide. This provides a lot of wiggle room for the presenter (Sr. Executive, Product Manager, Product Marketer or someone else) to paint a rosy picture of the future but never actually commit to anything.
Here are a few REAL roadmap images I pulled down from the web. Which of these companies uses Agile in the development shop? Can you tell? Does it matter?
Click on any image to enlarge to full size.
Suggest a motto for ProductCamp Toronto and if we use it, we’ll send you a ProductCamp Toronto t-shirt with the motto. You don’t even have to attend the ProductCamp to win!
But if you do attend, then we’ll give it to you onsite, and make a big fuss or something about as well, just to recognize your contribution.
That’s it, it’s really simple. Just leave a comment with your suggestion or email us: productcamptoronto at gmail dot com.
Here’s a little inspiration to get the creative juices flowing:
- ProductCamp Toronto: An Unconference in the Great White North
- ProductCamp Toronto: Participate, Captivate, Agitate, Permeate
- ProductCamp Toronto: Took longer to plan than the Federal election
- ProductCamp Toronto: A much better name than P-Camp!
Oh yeah, deadline is Wednesday October 26. 2008! We need time to get the shirts made for the November 2nd event.
Hope to hear from you.
ProductCamp Toronto is fast approaching.
It is on November 2, 2008 at the Ted Rogers School of Management at Ryerson University in downtown Toronto.
It’s an unconference. Participants get to decide the topics. Here’s a list of topics suggest by people like you. Make sure to scroll down to see the full list. It’s a Wiki, so edit the page to add your own topic.
Click here to cast your vote on the topics you want to are interested in.
Or check out the results of the survey so far.
And if you plan on attending, register here.
Hope to see you at the event!
April Dunford had a good post last week about Product Naming. She summed it up quite well with the three kinds of product names. Back in the day (circa 2000), on of my products was the focus of a corporate rebranding, and we spent a whack of money on a new company name, a product name, and a brand architecture. It was a real education for me personally, as I got to work with Interbrand, which is one of those companies who, like April described, just gets the naming and brand-image thing.
We ended up with two new names: Sitraka (company), and PerformaSure (my product), along with some nice graphics, logos, corporate colors, and a “voice” for the company. It was really slick, but also very expensive. There are some very creative people and small firms out there who can do this kind of work for a lot less, but with Interbrand, we knew we were going to get a great result.
Eventually it paid off, when the company was acquired. I know that the branding and the vision we were painting made us look much bigger than we really were, and attracted a great stable of acquirers. Or maybe it was just the great product we built!
I’d be interested in hearing from you (in the comments below) about some:
- great, but inexpensive, branding you’ve done. Shout out to the companies you admire for the great job they do on a budget.
- mistakes, flops, or bad names that you’ve seen or developed.
I’ll start the ball rolling: When I was at Fortiva, Evoke re-made our web presence. They did a fantastic job in a short time period, and again, really helped the company project an updated and large image. Here we are in their gallery.
And in the mistakes category, everyone has heard of how the Chevy Nova played in Latin America, or perhaps how “Roots” came across in the Sydney Olympics. But here’s one in Chinatown that made me laugh:
Curiously, the store appears to be out of business. Perhaps with such a concrete name, they couldn’t adapt to the market, which is focused on polyphonic harmony, going forward.