A Thought regarding a recent CrankyPM post

So I was reading this post from the CrankyPM regarding real estate postings that don't have enough information. A bad example of Product Marketing she says. I did some homework of my own to see if I got the same results she did. I did. The CrankyPM was quite disappointed.

The purpose of these ads is not to answer the three questions she noted:

1. Where is the home?
   
2. Is the home big enough for my family?
   
3. What’s the asking price?

What if the ad had all those things, but didn't have a picture. I'm willing to bet that fewer people would call than if there was picture, but the ad didn't answer all 3 of those questions. Buying a home is an emotional decision. People like to see the home and ask themselves "Can I see myself living there?". If the answer is "Yes" then the person will likely pick up the phone and call.

So at the end of the day, I disagree...the purpose of the ad is to get you to talk to the real estate agent. The ad serves its purpose and is designed to elicit an emotional response. It reminds me that the purpose of a resume to not to get you the job, but rather to get you the interview.

Any thoughts?

Product Manager = Generalist

So there was one point in my career, while walking through the break room I noticed several job listings. There was one in marketing, one in finance, one in development, a sales engineer, and one in quality assurance. I read through each one and I realized that I could do significant parts of all of the other jobs. At that point, I realized that as a product managers we are generalists. We need to be able to effectively communicate with literally every functional group in the organization to represent our products effectively. Everyone in the organization either doesn't know what Product Management does or only can only tell you the part of Product Management that interfaces with their team. As a result, no one person knows the entire set of all of the responsibilities of a product manager, except the product manager themselves.

This is probably the reason that Product Management location in company org chart varies widely from company to company. In technology dominated company (i.e. where the technology team dominates mindshare), the Product Management team falls under the VP of Engineering or the CTO, etc. In this type of org, they are primarily focused on supporting the needs of engineering such as requirements, etc.

In other companies, Product Management falls under the VP of marketing where they take a more market centric view. This involves product marketing assistance, market research, and competitive analysis. In this org, you see more market requirements than product requirements.

Pragmatic Marketing has a whole eBook on Product Management here.

Agile Roadmapping and Pragmatic Marketing

Today I attended the "Agile Roadmapping" webinar helded by Pragmatic Marketing. The folks at Pragmatic Marketing are top notch and I have enjoyed their classes and have become "Pragmatic Marketing Certified". Enough about me...the webinar was a total disappointment. The sound cut off and they spent most of the time talking about their travels. It got way off topic and it just glossed over the day to day struggles that product managers face developing roadmaps in an agile environment. So I've decided to dedicate this blogpost to providing my viewpoint and perspective in an effort to dig a bit deeper than the superficial.

The challenges:

• Setting Expectations - With agile your roadmap is very detailed during the current sprint and then becomes less so as you start to prioritize your product backlog. As for putting when items will be delivered, I would recommend only putting a timef rame down for the current sprint stories and then just putting the rest down in a priority. If executives don't like the fact that there is no time frame for that feature they want by the end of the year, work to educate them that scrum is the not the right process to guarantee delivery of a feature many sprints from now. Careful positioning of the roadmap is critical in the context of SCRUM.
• Crafting - A roadmap is an excellent communication tool for the vision of product management. Priorities, product themes, and overall initiatives can be communicated along with their value to the market. It must be updated often, preferably at the end of the every sprint as you learn more and have begun planning for the next sprint. An updated roadmap presentation including goals for the current sprint and how that fits into the remaining work for that particular feature or product. How many times have you had to scurry to update your presentation when you get an email from an exec who wants an update? If you updated it at the end of every sprint, it would be an easy request to meet.
• Time - Many times we are so busy being product owners and getting our heads around all of the incoming stories that we can't even begin to think about the market. Take time to get this done. Step away from the tactical a little bit...your team will appreciate it in the long run.

What are your thoughts?