The Productologist

This is probably the last Product Management Reader of the year. Not for sure yet, but probably. To keep you busy through the end of the year, here is an extra wonderful list of stuff to fill your days with. Unless you’ve got something better to do, which I HIGHLY doubt!

1. The Price of Leadership
   [Lead on Purpose]
2. The Famous ProductBeautiful Roadmapping Drinking Game
   [Product Beautiful]
3. An Engineer Roasts “Marketecture”
   [ProductMarketing.com]
4. How Product Management Must Change to Enable the Agile Enterprise
   [InfoQ]
5. Stop Giving Your Customers Too Many Choices — They Don’t Want Them!
   [Accidental Product Manager]
6. Against a Grand Theory of PM, part 1
   [Forrester Blog for Technology Product Management and Marketing]
7. Organising Agile Teams With A Visual Calendar
   [All About Agile]
8. Product Marketing is NOT Marketing Communications
   [Outside InView]
9. Guest Post: Measuring Product Management (part 3)
   [On Product Management]
10. Attainable Requirements
    [Tyner Blain]

Disclaimer: Including a link to a particular posting in the Product Management Reader  is not an indication that I agree with the original author. In fact, I may post topics that are the opposite of my views or at least somewhat controversial in order to provide a contrasting viewpoint to the one I present on The Productologist.

Popularity: 2% [?]

Related posts

• Resources (1)
• Welcome to The Productologist (2)
• Why the UI is Important (4)
• Clearly, You Aren’t Hearing Me (2)
• Fast Release Cycles (4)

Tags: agile, engineer, enterprise, leadership, Marketing, marketing communications, product management, product marketing, requirement, roadmap, software

Last week (3Dec09), Forrester Research Analyst Tom Grant led a discussion on Agile in Technology and how it pertains to Product Management. I took some copious notes on the discussion and thought I would share them here.

Be forewarned, some of this may seem a bit cryptic. I was typing in real time (on my new HP Netbook) and participating in the discussion, so I didn’t capture every single piece of the conversation. Plus, they’re notes, so by definition they are brief. I’ll try to add some clarity where  I can. Items with ** denote topics that were brought up as part of a response, but not discussed in detail.

<NOTES>

Agile in tech orgs requires company-wide changes to be successful

Topics for discussion (desired @ start)

• Multiple Groups
• Agile Adoption Path
• Communicating Up
• Roadmap
• Associated Groups
• Longer-term Projects
• Cult of Agile

**Does Agile get used for things other than software (service, hardware, etc)?

What does Agile really mean?

• Fail fast
• Rapid iterative sprints (vs. releases)
• Consumer v. enterprise
• Empowering for Dev
• Customers funding development of features (demise of PM?)
• Customers/requirements mob-style
• Discover issues more quickly

**Designating sprints as design or build can provide balance for dev team and product team

What are the characteristics that make Agile truly Agile (are there minimal reqs to be Agile)?

• Daily communication
• User stories
• Coaching (external training)
• Executive sponsorship

**Challenge of balancing defect/feature in sprint/releases

How can Agile better accommodate futures (12 month plan)

• Showing a long-term roadmap that likely won’t happen that way vs.  showing a 3 month roadmap that is likely, but without future planning
• Use backlog as “possible” roadmap

Challenges of Waterfall and Agile turn out to be very similar, but are labeled differently

1st age of Agile is done, moving to 2nd age where Agile is more broadly adopted and enhanced

</NOTES>

Popularity: 2% [?]

Related posts

• Resources (1)
• Welcome to The Productologist (2)
• Where Does All the Time Go? (1)
• Why the UI is Important (4)
• Using Human Factors in Design (2)

Tags: agile, backlog, balance, challenges, Customers, Design, forrester, product management, requirement, roadmap, sprint, tom grant, waterfall

Alright, people, Summer is over (again, just for you Northern Hemisphere dwellers)! Time to kick it back into gear. I hope you all kept up with your Summer reading list. You’ll be expected to discuss the following (with cited examples):

1. Thoughts: Duplicating the “Apple Effect”
   [AckNak]

2. Does a product manager have a natural life-cycle?
   [Carl Knibbs]

3. Tr.im should have figured out their revenue model first!
   [On Product Management]

4. Your Best Customers Probably Aren’t
   [Experience is the Product]

5. Agile Testing versus Waterfall Test Phases
   [All About Agile]

6. Your product launch wont be successful if your sales team doesnt trust you
   [Launch Clinic]

7. Mock-ups Made Easy!!
   [Product Ninja]

8. A Simple (?) Question …
   [Outside InView]

9. 10 Ways to Identify an Impending Product Launch Disaster
   [Launch Clinic]

10. Developing a Product Idea Presentation
    [Grace Hu-Morley]

11. What is a product specification?
    [Effectivus]

Disclaimer: Just because I include a link to a particular posting, that is not an indication that I agree with the original author. In fact, I may post topics that are the opposite of my views or at least somewhat controversial in order to provide a contrasting viewpoint to the one I present on The Productologist.

Popularity: 3% [?]

Related posts

• About (0)
• Less is More (2)
• Clearly, You Aren’t Hearing Me (2)
• Traveling with Technology (1)
• Fast Release Cycles (4)

Tags: agile, customer, Customers, mock ups, product launch, revenue model, waterfall

Last time on the Product Management Question Corner, I announced that there was only one more left to post. That was true, until Jason Miceli, self-described Product Ninja, answered my tweet requesting more volunteers. Jason is VP of Product Management at Perimeter eSecurity, a provider of on-demand information security services for enterprises of all sizes. Jason has a long history of working in IT software and leading IT projects. In this session, Jason provides some keen insights on being  a Product Manager in the trenches, as well as what’s the haps for Product Management leadership.

Q: How did you come into the role of Product Manager and was it planned?

A: Well that depends on what you mean by “planned”!  If you asked me 5 years ago if I planned to be in a Product Management role, my answer would likely have been, “Are you kidding me?”  However, the evolution that brought me to this ultimate role certainly felt natural – so you might say it was “sub-consciously” planned!

When I began working for my current employer I was hired as the Director of Special Projects, which quickly turned into the VP of Project Management after they saw the success of throwing a “special ops guy” at the crazy one-off projects that no one else either wanted or understood.  Once that role also proved to be successful the company made another course correction, stating they wanted me to focus my efforts toward the projects that produced revenue, thus my final transition to VP of Product Management.

Now at first I attacked this role primarily from a project management perspective, given my background to date, but then quickly began to fall in love with and embody the full sense of Product Management.  Now I truly could not see myself doing anything else!

Q: What was your worst Product Management mistake and how did you recover?

A: I’d say my worst Product Management mistake was probably being “too much” of a team player on one particular project.  At the time of this project we had a very clear line of delineation between the Software Development phase and the Product Launch phase.  This project had been in design and development for almost a full year, and so everyone in the company was nearing their limits with how much longer they would tolerate project delays – the notion of scrapping it had come up more than once.  Knowing this, and trying my best to convince executive management it would be a mistake to scrap the project where it stood, I prematurely “accepted” the project into the launch queue.  I said I would do my best to fast track the User Acceptance Testing (UAT) and public beta steps, hoping that would help everyone to see the light at the end of the tunnel…  unfortunately the product was still VERY deep in the tunnel, and so because I did not mutually accept the project’s discontinuance when I had the chance the result was a bit more egg on my face when that same inevitable outcome occurred.

Why did I take this approach?  Because I knew how much would have been lost by scrapping the project where it stood – efforts by my team and countless others to design the product’s functions, features, benefits, GUI design, database and systems architecture, prototype environment, hundreds of software development man-hours, etc. – it killed me to think about all that effort being lost and so I looked for any way I could to keep the project alive and not see it all go to waste.  In the end, no matter what happened it was destined to become a failed project, a reality every Product Manager must eventually face, but I made the situation far worse and essentially wasted more time and resources in the process.  A great learning experience to be sure!

Of course this case study would also be a great to show how an Agile methodology could have prevented this entire disaster from ever occurring in the first place!

Q: How do you see the role of the Product Manager changing in the next 5-10 years?

A: I believe the concepts of Agile are really starting to take off, and we’ll see a tremendous move towards that methodology over the next 5 years.  Accordingly, the notions of Product Manager, Product Marketing, Product Owner, and a couple other key roles will really start to take shape and become more widely known and understood throughout the industry.  This is a fantastic evolution, and one I will fully embrace and foster in any way I can!

Q: If you could be the Product Manager for any product, what would it be and what would be the first thing you would do?

A: Of the known, current products on the market I would gladly take product ownership of eBay.  eBay’s success is undeniable, but I believe there are key ways the core product can be enhanced to cater to a wider audience.  Most notably I believe the product’s accessibility is lacking.  Based on research I’ve performed recently there are many who choose not to post items on eBay due to the perceived complexity in doing so. While I don’t consider the overall posting process to be “complex” I do believe there are ways it can be modified to offer a far simpler and more streamlined approach that would entice the average user to make better and more frequent use of the system.

Q: What Product Management tool could you not live without and why?

A: At the moment I’d have to say Microsoft SharePoint.  I have been building out some fairly detailed custom tables that interrelate in ways allowing for fairly decent tracking and visibility of many Product Lifecycle Management (PLM) concepts.  Of course there are commercially available tools that do a far better job given their direct focus on PLM, but absent of the necessary budget dollars to purchase such a product I have found it surprisingly effective to recreate much of this functionality in SharePoint.  We started with a simple projects list and have since expanded to include our formal product catalog, user stories repository, supported platform matrices, regulatory language and mapping database, and several other tables, each of which link to associated master tables creating a very dynamic work environment.  Most importantly, creating structures like these within SharePoint has proved to be extremely simple – I was able to accomplish all of this myself, without seeking any assistance from engineers or development resources.

Q: What is your greatest Product Management achievement?

A: Building a thriving Product Management department from ground up – I truly could not be more proud of the tremendous success our team has been recognized for repeatedly!  One of my proudest moments was shortly after our new Chief Strategy Officer came on board and quickly admitted he had never seen Product Management working so well in any organization before.  In his words, “he has Product Management singing!”  To further that notion, I was equally proud the day I turned over management of all product launch responsibilities to a gentleman I had hired less than a year prior – to me there’s no greater measure of success for a manager than to build up a process to such a point of efficiency that it no longer requires his or her direct involvement!

Q: What have you done or what would you consider the best way(s) for Product Managers to improve themselves?

A: In every sense of the phrase, “Get out there!!”  Get out to the market and understand it.  Get out to your customers and listen to them.  Get out to conferences with your peers and learn from them.  Get out to the industry and become a leader.  Just get out there!!

What you should be building can come only after you’ve accomplished this – then you can be sure you’re building the right thing, the right way.

_____________

And now for Jason’s question for The Productologist:

Q: What would you consider the *best* possible organizational structure as it relates to Product Management, Product Marketing, Development, Corporate Marketing, and any other key department(s) you feel are part of this picture, starting from the CEO and working down?

A: The organizational structure of a company depends greatly on the size and maturity of the organization and the orientation of the leadership team. At most software startups, the Engineering team gets built first and then there is a realization that the founder(s) or Dev team are not in a position to actively manage the product, so they look to hire a PM to take over the reigns.

At more established companies, a new product is assigned to an existing PM, who likely has 3 or more products/services that they are already responsible for managing. If they are lucky, they are pulled off of the other products (or at least reduce their day-to-day responsibilities) to focus on the new product.

In either case, the PM has an uphill battle for time, attention, resources, and money.

In startups, PM usually falls under Engineering. In older organizations, they tend to fall under the broader Marketing umbrella or be a stand-alone team. Each structure has it’s strengths and challenges, which have been and continue to be debated in the PM community, but the one I think functions best for the role of Product Management is being a stand-alone team.

While this usually means giving up the stature, influence, and budget of being part of the Marketing or Engineering teams, the autonomy and ability to operate between these two powerful entities best suits Product Management’s true charter–to listen to and observe the market and provide guidance on how to maximize the value of that information into an executable product strategy.

Product Managers wear many functional hats and go by many monikers, but ultimately, their primary responsibility is to guide their product(s) to success, whatever shape that might take for their product or company. Success could be revenue or users or media attention or downloads (best to set that metric at the outset in order to make sure you are prioritizing correctly), but whatever it is, the Product Manager is the one whose head is on the platter if it doesn’t happen.

If Product Management sits within either Marketing or Engineering, I believe that they are too constrained by those teams’ other mandates to effectively perform their own duties. Don’t construe this to mean that I see PM teams that are structured within those teams to be doomed to failure. I have, in fact worked on teams in both of those scenarios, with much success. But at the time, my PM goals, as designed by the executive team, were aligned with one or the other of Marketing or Engineering, which is why those arrangements worked. I don’t see that as being ideal for the true function of Product Management.

Having a stand-alone Product Management team means that you have to have STRONG Product Management team. Ideally, it means have a VP of Product Management who is on the same level as Marketing and Engineering, reporting directly to the CEO (or COO or whomever Marketing and Engineering report to). That gives Product Management a voice at the executive table and enough influence to drive not just the product roadmap, but the product strategy.

If there isn’t a VP of Product Management, then you really have to have STRONG Product Managers. And by strong, I mean being able to go into the CEO’s office and say things like, “No” or “I need X to make this product successful” or “We can do that, but that will affect all of our current product plans for the next X months. Here’s why I wouldn’t recommend that.” With data to back you up, of course, but you have to be able to say those words. Otherwise, Product Management will always be a second-class citizen to some other organization that can say those things.

So in an ideal world, here is what the corporate structure looks like (I have not gone into detail about what happens within other teams, just the product team):

A word about UI design sitting within the Product team. I think this is a crucial element of the Product team that is missing 99% of the time. Design is an important market requirement, and too often it is relegated to the function of making already-built functions “prettier.” Design in software is more than look-and-feel. It is the workflow and ease-of-use and extensibility of the user experience. Design is fundamental in the success of software. Apple is the quintessential example of this. I am no Apple fanboy, but I recognize the obvious fact that their products START with design, rather than end with it.

A bit more about Jason:

Jason has held key leadership positions within his organization for the past five years.  He is directly responsible for a portfolio of 30+ services totaling over $30 million in revenue and has helped to define the rapidly emerging Software as a Service (SaaS) market within the security and technology space.  Often referred to as the “most detail-oriented person who can remain optimistic,” Jason is further unique in his love for the “art” of creation.  In addition to product management, Jason has served as the lead for key mergers & acquisitions, new remote offices, and department startups, responsible for smooth integration of new products, staff, and business processes. Jason is published in several security magazines, including CSO, and was recently a speaker at ISPCON.

Popularity: 5% [?]

Related posts

• Welcome to The Productologist (2)
• Why the UI is Important (4)
• Hiring for Success (3)
• Using Human Factors in Design (2)
• Fast Release Cycles (4)

Tags: agile, agile development, business problem, challenges, customer experience, Customers, diagrams, enterprise software, feature set, Interviews, large corporations, Management, measure success, priorities, product management, product roadmaps, product team, product vision, release cycles, software development life cycle, start ups, stategy, Usability, user experience, users experience

It’s late (or early, depending on your perspective) and I can barely see the text as I type because my eyes are so bleary. I know that if I don’t write something witty here, one of you will send me an email complaining that I didn’t write anything witty here. Well, fear not, gentle readers, I will write something witty here. I have it around here somewhere…oh yes, now I remember, I wrote it in the leftover tomato sauce on my plate from dinner. I know, not ideal, but when an idea strikes, you MUST write it down, lest it be forgotten and that’s all I had available. I’ll just go fetch my plate from the table. OH NO! The dishes! They are…in the dish drain! And clean! Who could have done such a foul deed? Certainly not me…oh, cruel world, why must you punish me so?

1. Three P’s of business success
   [Lead on Purpose]

2. Summer’s here: Do something different
   [On Product Management]

3. 6 Lessons for Non-Dev Executives at Agile Companies
   [ProductMarketing.com]

4. Google Chrome OS: Dissecting A Great Marketing Announcement
   [Rocket Watcher]

5. Writing Complete User Stories
   [Tyner Blain]

6. Next-Generation Conference Room Phone Design Ideas
   [Silicon Valley Business Catalyst]

7. Product management and marketing mix it up
   [Forrester Blog for Technology Product Management and Marketing]

8. Bloggers miss the point of buyer personas
   [Buyer Personas]

9. Business-Driven Product Management
   [Product Management Pulse]

10. Viable Product or Service First, Then PR
    [Twilight in the Valley of the Nerds]

11. Idea Management Vs Innovation Management
    [Purist Product Management]

Disclaimer: Just because I include a link to a particular posting, that is not an indication that I agree with the original author. In fact, I may post topics that are the opposite of my views or at least somewhat controversial in order to provide a contrasting viewpoint to the one I present on The Productologist.

Popularity: 3% [?]

Related posts

• About (0)
• Welcome to The Productologist (2)
• Why the UI is Important (4)
• Using Human Factors in Design (2)
• Traveling with Technology (1)

Tags: agile, buyer personas, Design, Innovation, innovation management, Marketing, nerds, Personas, product management, silicon valley, technology, UI, viable product

Today’s edition of the Product Management Reader is powered by gin and tonic, so pay extra close attention for bonus wittiness and idle banter. And would you believe two separate posts from two separate Product Management bloggers about blenders? BLENDERS! It boggles the mind. Plus, there may be an exhibition by that ever-elusive double entendre. Eyes wide open, now.

1. Agile Maturity Model – What’s Next?
   [Tyner Blain]

2. Advice for up and coming Product Managers
   [All About Product Management]

3. The Quarterly Vacation
   [Product Management Zen]

4. How the Blender illustrates “designing the product” vs. “designing the whole product experience”
   [Experience is the Product]

5. The value of simplicity
   [On Product Management]

6. I blame the the Product Manager
   [Cranky Product Manager]

7. VC Pitch Template
   [Rocket Watcher]

8. Lessons from a Bad Haircut
   [Requirements Defined]

9. Visiting customers “in the wild”
   [ProductMarketing.com]

Disclaimer: Just because I include a link to a particular posting, that is not an indication that I agree with the original author. In fact, I may post topics that are the opposite of my views or at least somewhat controversial in order to provide a contrasting viewpoint to the one I present on The Productologist.

Popularity: 3% [?]

Related posts

• Why the UI is Important (4)
• Using Human Factors in Design (2)
• Fast Release Cycles (4)
• Fighting, er, Working with Engineering (2)
• Ethnography or Just Good Requirements Gathering (8)

Tags: agile, Customers, Design, maturity model, product experience, product management, Requirements

I have recently been embracing the change from traditional waterfall product development to an Agile framework. In the past, I have been wary of Agile, especially for enterprise products, but as I gained a better understanding of the Agile principles, I started liking it more. There are still caveats for using Agile methods and success of Agile process depends heavily on the staff managing the framework, but I am starting to see why Agile development is so appealing.

From a Product Management perspective, one of the most appealing aspects of Agile is how requirements documentation works. For many years, I spent a ridiculous amount of time creating requirements docs (primarily MRDs, but also some PRDs and TDDs). The reason for this is that MRDs have a broad audience. The same MRD that Developers and QA Engineers use to build their functional requirements also has to be read, understood, and digested by folks from the Sales, Support, Pro-Serv, and Marketing.

That means MRDs are chock full of data which can include some or all of the following topics:

• Business Case
• Revenue Model
• Competitive Analysis
• Market Analysis
• Feature Descriptions
• Feature Design
• Staffing Requirements
• and the kitchen sink

All of this data makes for a large and cumbersome document, both to create and to absorb. On more than one occassion, I have had to chase down folks who insisted on getting a copy of the MRD (and who promised to provide feedback), only to find that they had not even read it 3 weeks after I sent it to them (and sent out multiple reminders).

Ugh. A lot of work with little or no benefit.

What I like about Agile development is that most of the extra “fluff” is moved out of the requirements process. It’s usually still there in the release cycle, but it’s someplace else, like a hallway conversation with your CEO, or a presentation to the exec team, joining the Sales/Support team’s weekly staff call, or an on-going discussion with your manager. Those are the folks that care about the fluff part of requirements docs.

When you work with the Dev team, for the most part, they don’t care about the specifics around revenue, competitor analysis, or anything else not directly related to helping them write the code. That’s not to say they don’t care at all. Revenue should be very important to ALL employees, but as information that Developers need to do their jobs, those things just to add much value.

So, instead of a 30-page MRD, I like the 5-10 page release specs doc. I focus on what is in the release and what it should do. I usually add a bit about what problem it solves or how it would be useful so that the Dev team can use that information to better understand the requirement, but not much more than that.

To be honest, the short-n-sweet option doesn’t always work out as well as I would hope. It still requires having some lengthy discussions with Developers to iron out issues, but I’d have to do that with the big MRD, too, so why not save time and not write it, and then focus on getting the software built and into the hands of testers and users?

Less work for the Product Manager, which means more time to get out into the field, spend time with customers and partners, and listen to folks explain how I can help them with my product. Everybody wins!

Popularity: 4% [?]

Related posts

• About (0)
• Resources (1)
• Welcome to The Productologist (2)
• Less is More (2)
• Why the UI is Important (4)

Tags: agile, agile development, agile methods, business case, competitive analysis, customer, Customers, Documentation, Engineering, feature descriptions, feedback, functional requirements, Manifesto, Marketing, MRD, product management, QA, release cycle, requirement, revenue model, Sales, Support, users, waterfall

On the road again…but that can’t stop the music. Just gotta keep on truckin’.

1. What if…
   [Product Beautiful]
2. When is a Feature Request a Customer Requirement?
   [Effectivus]
3. Guest Post: The Cranky Marketer Goes Off (Part 1)
   [Cranky Product Manager]
4. 2008 User>Driven Hall of Fame and Shame
   [User>Driven]
5. Is Facebook’s Zuckerberg Right? Sometimes Listening to Your Customers is “Stupid.”
   [Rocket Watcher]
6. Six Characteristics of Product Managers
   [On Product Management]
7. What makes us tick
   [Agile in Action]
8. Two questions product managers must always ask
   [Product Management Tips]
9. Are you ready to be a technology manager?
   [ProductMarketing.com]
10. Value Propositions 101
    [Rocket Watcher]
11. Good Visual Design without Good Interaction Design = Crummy Facebook Redesign
    [Experience is the Product]
12. The 10 most common reasons for poor usability – part 1
    [Experience Solutions]

Disclaimer: Just because I include a link to a particular posting, that is not an indication that I agree with the original author. In fact, I may post topics that are the opposite of my views or at least somewhat controversial in order to provide a contrasting viewpoint to the one I present on The Productologist.

Popularity: 14% [?]

Related posts

• About (0)
• Resources (1)
• Welcome to The Productologist (2)
• Less is More (2)
• Why the UI is Important (4)

Tags: agile, customer, Design, feature request, Marketing, product management, requirement, technology, Usability, value propositions

With #PCAMP09 wrapped up this weekend (oh, and St. Patty’s day), I thought there would be more posts like mine (or at least more than 1) about the comings and goings of Product Managers talking about Product Management and Product Management issues with other Product Managers. I guess that all happened on Twitter.  Anyway, this week we have a couple of double dippers and Gopal hit a triple.

1. Guest Post: The Cranky Sales Engineer Shares Sales Secrets
   [Cranky Product Manager]

2. To the Agile Community – WTF is wrong with you?
   [Cranky Product Manager]

3. Outstanding P-Camp this weekend
   [Forrester Blog for Technology Product Management and Marketing]

4. Why Does It Have to Be That Way?
   [The Experience is the Product]

5. Messenger of problems?
   [Product Management Tips]

6. Futility of “feature wars”
   [Product Management Tips]

7. Product Management in a Start-up
   [Confessions of a Digital Immigrant]

8. How Product Managers Can Get Better At Creating Powerpoint Slides
   [Accidental Product Manager]

9. Product Managers & The Secret Of The Color Wheel
   [Accidental Product Manager]

10. Career transition from software developer to product manager
    [GeekMBA360]

11. More “New Facebook” Disasters – Six Things I Really Hate
    [Tales from the Digital Side]

12. Are Product Management Frameworks, User Experience The Secrets To Success?
    [Product Management Meets Pop Culture]

Disclaimer: Just because I include a link to a particular posting, that is not an indication that I agree with the original author. In fact, I may post topics that are the opposite of my views or at least somewhat controversial in order to provide a contrasting viewpoint to the one I present on The Productologist.

Popularity: 17% [?]

Related posts

• About (0)
• Resources (1)
• Welcome to The Productologist (2)
• Why the UI is Important (4)
• Clearly, You Aren’t Hearing Me (2)

Tags: agile, career, color wheel, Facebook, forrester, management frameworks, MBA, pop culture, product management, product manager, software, Startup, technology, twitter, user experience

At this year’s P-Camp, I learned a lot of things. Some about Product Management. Some about people. And some some about organization. Here’s a short list of my observations and learnings. If you are on twitter, search for the tag #pcamp09 or #pcamp to see what other folks thought. I’ll be back next time.

1. Even unorganized events need organizing (thanks, Rich and team)
2. Discussions serve a different purpose than presentations
3. Topics are just the starting point
4. Just like in the real world, squeaky wheels get the grease
5. Equal access to participation is not equal participation
6. Product Managers sometimes have to act like Sales to get their message out
7. Labels, definitions, and functional inconsistencies continue to be the bane of Product Managers’ growth as a profession
8. Every product has problems; every Product Manager has problems; sometimes they overlap, sometimes they don’t
9. User Interface == User Experience
10. Requirements are not the answer
11. Product Managers are friendly, if you say hello first
12. It’s hard to twitter and pay attention
13. Product Management is a “renaissance” role
14. Agile is a good tool, but not salvation
15. Product Managers are part of the problem
16. Product Managers fill the voids left by other roles
17. Others fill voids left undone by Product Managers
18. Product Management is political
19. Product Managers, as a general rule, spend too much time NOT listening to the market

For more information about this P-Camp, check out the Facebook group, LinkedIn group and the wiki.

Thanks to all who planned, staffed, and participated.

Popularity: 17% [?]

Related posts

• Why the UI is Important (4)
• Using Human Factors in Design (2)
• Fast Release Cycles (4)
• Fighting, er, Working with Engineering (2)
• I am NOT the CEO of my Product (7)

Tags: agile, definitions, Interface, learnings, product management, real world, renaissance, Requirements, UI, user experience, user interface