Product Manager vs. Product Management (part 6)

In part 5, I showed how you can begin to decompose the areas where teams, particularly Product Management, provide key deliverables to other teams. Here’s what the heat map looked like for Product Management across the stages of the development cycle.

(click to enlarge)

For each colored element in the heat map, a list of deliverables and dependencies for that team at that stage of the cycle must be defined.

One important note here. Even though the chart above lists discrete stages in the development cycle, the stages can and likely will overlap in time. For example, Pre-Beta, Beta and Post-Beta all occur during the Product Development stage. And the Sustaining column is a set of ongoing deliverables that occur throughout all of the other stages and feed into stages such as Product Definition.

So, if one were to take a stab at listing the key deliverables at each stage of the development cycle, it could look something like this.

(click to enlarge)

I say “could look something like”, because it will vary somewhat from company to company, and possibly even from product to product. For example, A hardware product, e.g. an appliance, will have different deliverables at certain stages than a client-based software application. And the client-based software application may have different deliverables from a hosted SaaS application. Having said that, the stages and deliverables listed in the chart are relatively generic and should apply in many circumstances. And finally, some of the items may better fit in other columns depending on the company and the specifics of the situation. e.g. demo creation may take place later in the development cycle, closer to launch, may not even be a Product Management deliverable in certain companies, or may not even be needed at all!

In the context of the Information Supply Chain, when thinking of deliverables, there are upstream dependencies and downstream dependents. Upstream dependencies are any deliverables that must first be completed by yourself or others, in order for you to create your deliverable. For example, a good Product Requirements Document (PRD) might depend on the existence of a Market Requirements Document (PRD). Thus the MRD is an upstream dependency of PRD. Conversely, for every deliverable, the downstream dependents of the deliverable must be identified and documented. e.g. For a PRD, the downstream dependencies can include Functional and Design Specifications created by Engineering and Product Description and Overviews created by Product Marketing.

Now let’s look at the first column and drill down some more.

It has three potential deliverables:

• Statements of Direction
• Market Requirements Document
• Product Roadmap

Each of these needs to be defined and the dependencies (upstream and downstream) need to be identified. Luckily for Product Management, there are very few upstream dependencies in this case. Here’s the text for the Statements of Direction:

Statements of Direction (SODs) These are high level strategic documents, describing a number of characteristics about a new or needed technology or functional area to be added to the product. A typical SOD should be about 2-3 pages in length maximum . i.e. not lengthy.

SODs are typically theme based documents (e.g XML, Web Services, 64-bit Computing etc.) that describe major milestones needed across releases for given themes. A good SOD should include an “elevator pitch” describing the theme, a market or technology overview, including competitive info and market risk if necessary, the case for change and benefits for implementing the change, and a summary roadmap for the theme.

Internal Consumers: Product Management, Product Strategy, Development, Product Marketing External Consumers: Strategic Customers and Partners

Downstream Dependents: A Statement of Direction provides the necessary input for Product Marketing to create a “Point of View” (POV) document. Multiple Statements of Direction, defining objectives for multiple themes provide key input for Product Roadmaps

NOTE: A POV is an external facing document that can be used by Sales to convey product intent on a particular theme to customers/prospects/partners without revealing internally sensitive information

As you can see, this is a clear and succinct definition that describes the intent, general contents and consumers of the document. In this example I’ve added the NOTE to show an explicit downstream dependency of a Statement of Direction.

Here’s the definition of the Market Requirements Document. This should be familiar to most, if not all of you.

Market Requirements Document (MRD) MRDs are quite commonly produced by Product Management and/or Product Marketing. More applicable to new products, MRDs, like SODs, are strategic documents, but typically provide much more detail about the market dynamics and market sizing, the competitive environment, the business case for developing the new product as well as likely go to market strategy options.

In short, the rationale for a new product is thought through and documented. Should the internal or external environment change, the MRD can be reviewed, updated and then reassessed to see if the new product is still justified, or what needs to be changed from a business perspective to continue investment in the new product.

Internal Consumers: Product Management, Product Marketing, Product Strategy and Senior Management. External Consumers: None

Downstream Dependents: Product Requirements Document, Positioning Documents Upstream Dependencies: None

And finally the Product Roadmap:

Product Roadmap Product roadmaps are important tools in many sales situations. Prospects, customers and partners want to know that the vendor has a solid future plan that covers key areas of concern or need.

A roadmap should provide a high level view of key product releases and major functionality over time. Most roadmaps cover 12 to 18 month time frames and at least one major version release into the future. Roadmaps are typically communicated to external parties by Product Managers, Sr. Management and senior members of the sales and sales engineering team. Keep in mind that roadmaps represent a projection of plans into the future, and while one can strive to be honest about those plans, roadmaps do not in any way indicate commitments to deliver any specific functionality in any specific release or by any particular date. This must be conveyed explicitly to those who receive roadmap information

Internal Consumers: Product Management, Senior Management, Sr. Sales and Sales Engineering staff. Others on an as needed basis. External Consumers: Customer, Partners, Prospects

Downstream Dependents: Product Requirements Documents Upstream Dependencies: Statements of Direction

So there you have it. The first column of the Deliverables table is now defined. The task for you is to go and try this on your own for other items in the table. Pick a couple of them and work on the definition, the consumers and the downstream and upstream dependencies. Feel free to to post some of them in comments on contact me if you have some questions.

It’s important to work through this exercise within your own company. Explicitly understanding not only what you need to do, but who you depend on and who depends on you across the stages of the development cycle is a very important exercise. I can almost guarantee that you will find a few surprises and challenges as you work through the process.

Saeed

Related Posts
Product Manager vs. Product Management (part 1)
Product Manager vs. Product Management (part 2)
Product Manager vs. Product Management (part 3)
Product Manager vs. Product Management (part 4)
Product Manager vs. Product Management (part 5)

A no-demo tradeshow…

So, a few weeks back, a number of Product Management bloggers were invited to participate in a “blogfest” (blogapalooza?), responding to Steve Johnson’s post entitled “Why Demo at Tradeshows?“

Both Ethan and I responded to the call.

Having said what I said — give me the opportunity to have a meaningful one-on-one conversation with a valid prospect, and I’ll certainly trade a quick demo for it — I’m a bit surprised that I recently attended a small summit and tradeshow (200 attendees), and in two days, had a number of conversations with a number of individuals at our small “demopod”, and never once did I show running software.

A few key Powerpoint slides and references to the product brochures and data sheets were all that was needed to explain what we did, answer questions and scan their badges.

So, on one level, I admit that Steve (and those who agreed with him) had a point about tradeshow conversations. But on another level, I must also say that the small size of the show was a factor. Many of the people were more interested in the iPod we were giving away versus the software we had to sell.

So, perhaps the attendees read Steve’s article and agreed with him that they didn’t need a demo, or perhaps they were simply preoccupied with the end of the quarter, or maybe they wanted a demo, but because we never offered one, they didn’t muster the courage to ask. Or, maybe there was another reason, but in the end, I noted, somewhat surprisingly that after two days, no demo was presented. A first in my experience.

Saeed

Doing Better Demos

A post today on Adaptive Path’s Blog seems apropos to the discussion of tradeshows. Want to do a better demo? Learn the secrets of pick-up artists!

Why Demo At Tradeshows?

So I have to go with Saeed here in response to Steve’s posting on tradeshows. Just because a lot of companies handle trade shows badly doesn’t mean they’re worthless. Most companies can’t do email marketing right either; I would not suggest that you stop emailing customers and prospects.

But before we think about what to do at the trade show, let’s review what a Product Manager can get out of a trade show. Two things: one, leads and two, conversations.

Now, leads may not be your direct responsibility, but everyone needs leads. Are trade shows the cheapest way to get leads? Nope. Are they the best way to get leads? Nope. But unless you generate more leads than your salespeople can handle, you need more leads. Even if you have too many leads, how many highly qualified leads are coming in through your other lead generation channels? (The answer is never enough!) Web- and email-based marketing is the #1 source of leads for many B2B companies and I can come up with plenty of ways that companies do web and email marketing wrong. That doesn’t mean they should stop doing it.

You need to have an ecosystem of leads, just like you need to have customers in more than one region or vertical market. And trade shows remain a good way to get new leads. I hate scanning badges as much as anyone, but it works.

Also, if you can’t prove that trade shows are generating quality leads for you, then that’s not the trade show’s fault. Implement close-loop leads tracking! You have a CRM system right? Creating a campaign in Salesfore.com and seeing how many opportunities result from it isn’t rocket science.

Second, conversations. A trade show lets you have longer, more fully engaged conversations with both customers and prospects. Prospects are key here - when was the last time you talked to someone who was actively looking to buy a product like yours but wasn’t yet in your company’s sales funnel? Talking to prospects is so important because if you only ever talk to customers you’ll never find out about what the people who decided not to buy your product think. Prospects can decide not to even consider your product or service based on your positioning, without ever talking to a salesperson. I have yet to find a better venue than a trade show to meet these people and talk to them.

Conversations at trade shows are also more casual and relaxed because of the whole circus-like atmosphere of the show floor. (Being at a circus is great, as long as you’re not one of the clowns). Customers have come up to me and said “I love your product! I use it every day!” I rarely get that sort of enthusaism over the phone during customer calls. Customers have also come up to me and said “I like your product very much. There are twelve things wrong with it. They are…” - I heartily recommend doing a few trade shows in Germany because you will get this kind of feedback from more than one person. It’s great. When you work in enterprise software (my experience has been in development tools and IT management tools) you rarely get to have an animated conversation about the strengths and weaknesses of your product. The development team has never actually used the product and my wife and friends don’t really understand what I’m talking about when I try to explain what I do. Trade show conversations have provided me with months’ worth of stories and user feedback that I trot out during requirements planning sessions.

So, can you do trade shows wrong? Sure. Any marketing activity can become a mindless exercise if you lose track of what your real goals are. But we need to do trade shows.

So, why demo at trade shows? Come on - people need something to look at. Imagine going to an auto show where there was nothing but booths and flyers about all the hot new cars. (Let’s ignore the booth babes for a second. Besides, I haven’t seen a booth babe in years at the Toronto Auto show. I think they may be extinct north of the 49th parallel)

The demo isn’t the goal - it’s just a tool to get people’s attentition. Entrepreneurs talk constantly about honing their elevator pitch. There better be more to your business plan than your elevator pitch, but that’s what the demo is at a trade show. It’s the shiny, animated prop that backs up your elevator pitch. Actual software that’s more than just canned Powerpoint slides says that you have a real product that goes with the pitch. Right or wrong, this is the bar that trade show attendees want to see before they’re going to stop and pay attentition to you. And once you have their attentition, you get to do the two really important things: scan their badge and have a conversation.

As a side note, one product I demoed at trade shows was a web-based marketing automation system. It was next to un-demoable. It worked great, but it was challenging to develop, deploy and track an integrated email marketing campaign in five minutes. (I probably could have done it in ten minutes ). But as I went through the pitch, everyone wanted to see something. One person wanted to see reports, one person wanted to see how to compose email, someone else wanted to see how the automation system worked. This was really a polite way of saying that I was full of sh*t and that there was no such product. My “demo” didn’t really show all that much but it proved that I had a real product, which made my message a lot easier to accept and remember.

What’s the deal with tradeshow demos? (abridged and full versions)

In a blog posting, Steve Johnson of Pragmatic Marketing asks “Why Demo at Trade Shows?” Good question.

Abridged version

Why demo?

Steve writes:

Do we think that the product will sell itself? … Instead I fear that we’re showing too much too soon in the sales cycle and turning off our potential buyers.

I have to ask the question: Steve, what evidence is there that trade show demos turn OFF potential buyers?

Steve, you bought an iPhone right? Steve Jobs demo’d it at an Apple Conference a few months before they went on sale. What was the sales cycle that ensued that convinced you (and 100,000+ others) to get it as soon as it was available? I’m pretty sure it sold itself.

Full version

Why demo?

Why even attend trade shows at all for that matter? All those airline tickets and hotel rooms, not to mention trade show booth rentals, cost serious $$$. And then there are all those people who just come to your booth to get the nifty pen or other cool swag you have on hand.

What a bother!

But let’s get back to to the original post. Steve writes:

Back in its heyday, Comdex estimated that they threw away two tons of product literature every day. If they don’t keep the collateral, will they remember the demo?

Steve, a bit of logical fallacy here don’t you think? Sure, people throw away literature at trade shows. That doesn’t mean they throw away ALL of their literature, and it doesn’t at all imply they suffer from memory loss.

At it’s peak, Comdex attracted about 200,000 attendees. A bit of math (the numbers work out quite conveniently), and we see that (2 tons) 4000 lbs / 200,000 people = .02 lbs per person of wasted literature each day.

That’s about 9 grams per person. Not really a lot when you think about it. So, if people aren’t actually throwing that much away, maybe they are remembering the demo?

Later Steve writes:

Do we think that the product will sell itself? … Instead I fear that we’re showing too much too soon in the sales cycle and turning off our potential buyers.

I have to ask the question: Steve, what evidence is there that trade show demos turn OFF potential buyers?

Steve, you bought an iPhone right? Steve Jobs demo’d it at an Apple Conference a few months before they went on sale. What was the sales cycle that ensued that convinced you to buy it? I’m pretty sure it sold itself. Or at the very least, the Steve Jobs reality distortion field helped convince you to buy it.

BTW, if the product can’t sell itself, whose fault is that? Sure not all technology products are right for trade show demos, but that doesn’t mean none of them are. I had a wonderful experience a while back demoing a software product at a show. Could have sold lots of licenses on the floor if it were possible.

Many people attend technology trade shows explicitly for the opportunity to see a live demo of a product and speak directly to savvy personnel from the company that makes the product.

Ever watch a late night infomercial? They are nothing but extended demos of the products — kitchen devices, exercise machines, you name it. And boy do they sell product. One of most popular products sold by infomercial is the Showtime Rotisserie, pictured here. It is claimed that over 7 million units have been sold, generating revenues of over $1,000,000,000 dollars.

Steve continues:

Do the sales people demand it? Demo-selling is the laziest kind of selling. It says, “I don’t want to know you or learn your business. I just want to get you to buy as quickly as possible.”

I have to respectfully disagree here. First of all, as mentioned earlier, many people go to shows with the expressed intent to see the product and get a demo. Demo-selling is only lazy IF the vendor explicitly doesn’t want to listen to the prospect. In fact, if that is the case, it is not only lazy, but incredibly foolish as well. And yes, some companies do behave that way, but many companies don’t.

The great thing about trade shows is that in exchange for a short (not necessarily canned) demo of the product, I get to have face to face conversations with potential buyers. What’s my response to someone who comes to the booth and says:

“Hi, can I get a demo of your product?“

I say,

“Yes, absolutely. But first can you tell me a bit about yourself and what you are looking to do with a product like ours?“

If the person bites and responds to the question, then I have them. I can ask them a few more qualifying questions and if they fit the profile I’m looking for, I can get into a demo with them and continue the conversation, asking questions, probing for information etc. If they don’t fit the profile I can still give them the demo I promised, but I can decide how deep or not to take it. In the end, I get what I want, and they get want they want. Seems reasonable to me.

Later Steve writes:

Why do we demo at trade shows? Because everyone is doing it? My mother used to ask, “If everyone jumped off a cliff, would you?”

My mother used to say the same thing, but never in the context of tradeshows.

Just because everyone is doing it, it doesn’t mean it’s stupid.

I have a friend who was vacationing in Thailand a couple of years ago. He was sitting down to have breakfast with his wife and son. As they were eating breakfast on the restaurant patio, they started noticing people running up the road. As they watched, the number of people running up the road continued to increase. Many of the people were yelling in Thai as they ran by. My friend didn’t understand Thai. But, he figured that if so many people were running up the road, he and his family should do it as well. They abandoned their breakfast and ran along with the throngs of other people, not knowing why everyone was running.

The date was December 26, 2004. The people were all running up the road away from the beach and the massive tsunami that was bearing down on them. We don’t always have all the data to make well reasoned decisions on what to do, but many times, by observing crowds, we may get insight that delivers significant benefit.

There certainly are ways to have bad demos and to promote and sell products poorly. Some companies do it far too regularly, by focusing on their own features and functionality and not understanding the customer’s frame of reference. But that has nothing to do with a trade show. Alan blogged about this in one of his posts.

Steve concludes:

At your next event, try just asking people who come by the booth a few simple qualifying questions about their problem and its urgency to them. If they answer in the affirmative, scan their badge or take their card and invite them to enjoy the show. Meanwhile send a set of materials to them through the mail or better yet, have a sales person contact them the week after the show. Nobody retains information from a trade show–everyone is yelling to be heard. Perhaps you could be a little quieter and much more effective. Let’s use the demo where it belongs, much later in the sales cycle.

Steve, that’s an interesting idea. We have a big product launch coming up in September. We’re announcing the product at a big trade show at the Moscone Center in San Francisco. Now, I’m wondering, what would be the reaction of someone who took time off work, came down to the Moscone Center (maybe they are local, maybe they flew in for the show), and came to our booth and after a short interchange, I scanned their badge and sent them off to the next company of interest.

Hate to say it, but I doubt the impression would be a good one. What ROI are they getting from me, having spent time and money to come to my booth? A handshake, a short conversation and a “we’ll have a sales rep contact you next week“?

I’ll think about your idea. But to be honest, when I have the opportunity to have a high touch, high value direct conversation with a good prospect, I’m going to take it.

Saeed

How to be a GREAT Product Manager (part 5)

Be an integrator, translator and communicator. Don’t be a terminator.

I’m sure you’ve heard the phrase that Product Managers are “the hub of the wheel”. I really don’t like that line. Who wants to be the hub of any wheel? That’s like saying someone is the hinge of the door or the latch of the hood. Boooring! And not true.

Product Managers are collectors, analyzers and dispensers of information. They are routers of information flow. And being a great product manager means understanding how to optimize the information flow so that other teams in your company who are directly or indirectly dependent on you for information get it in a timely manner and in a form they can understand and use.

The following image is a coarse example of the major communication paths that exists in a software company. The blue are internal teams and the red are external.

[click to enlarge]

I say a coarse example, because it really only represents a high-level view of how information flows. Not all links in the diagram contain the same amount of information flow; not all nodes contribute as much information as they receive; and to keep the diagram from becoming cluttered, a number of links that rightfully should be shown are not.

I call these communication pathways the Information Supply Chain. And as a Product Manager, you are directly or indirectly responsible for a lot of the product and technical information that flows throughout your organization. How many times have you been asked if certain functionality is in an upcoming release? Or when a particular release is coming out? Or the details of a beta program? Or whether any pricing or packaging changes are being made to address market needs?

People are asking these questions because they are making decisions and need information to decide wisely. You can have a significant positive impact on those teams if you understand what information people need, when they need it, and in what form they need it? If you can do that for them, they’ll be able to make educated decisions sooner, streamline their work and be more effective. Deliver meager, late or difficult to understand information, and the opposite occurs. There is a real top-line impact to poor information flow in a company.

If you really want be analytic about mapping out the flow, you can do that. You need to look at all the stages of the product development cycle, from conception to completion to launch and beyond, and map out what information different groups need and when they need it. One way to represent it is via a heatmap that may end up looking something like this.

[click to enlarge]

The coloured cells represent areas where communication happens during the development cycle. The deeper the colour, or higher the number (from 1-3 in this case), then the more activity and information flow that happens. As you can see, Product Management is deeply involved in the information flow through all phases of the development cycle, but most heavily early on and in the middle, whereas Marketing and Sales, for example, really start toward the middle and have heavy information flow from the launch stages onward.

By understanding this, you can determine what information you need to produce and deliver to those groups to optimize their activities and decisions. Keep in mind that this is not solely a task for Product Management. Ideally all groups in the company use this analysis to optimize their communications. But, if you want to apply an 80/20 rule (80% impact for 20% effort), then teams like Product Management and Product Marketing must be the first ones to optimize their information flow to other downstream groups.

As technology workers, we exist in an information economy. And just like the manufacturing world, where materials, parts and inventory requirements are optimized for efficiency and minimizing costs, information needs can be understood and delivery processes optimized for greater efficiencies. And because of our role in defining product direction and driving strategy, Product Managers can play a key role in optimizing the Information Supply Chain. The question is, are you up to the task?

Saeed

Part 4 - The 4 Cs of leadership

Part 6 - Own the product from conception to completion and beyond 

How to be a GREAT Product Manager (part 4)

The 4 Cs of leadership: credibility, commitment, communication and courage

Product managers need to be leaders. A truism no doubt. But what does being a leader really mean and how can a product manager be a great leader? Let’s start by talking a bit about authority and responsibility. Both are words related to leadership.

Responsibility: noun. a form of trustworthiness; the trait of being answerable to someone for something or being responsible for one’s conduct; “he holds a position of great responsibility”

Authority: noun. the power or right to give orders or make decisions; “he has the authority to issue warrants”

Responsibility is both a trust and a duty. Authority is something you are given or possess related to your responsibilities. The two are clearly inter-related. If you have the responsibility to do something (e.g. uphold the law), you are given the authority to do the things that need to be done to deliver on your responsibility (e.g. issue warrants).

In cases such as law enforcement, both the responsibility and the authority are explicitly defined. In the case of many business functions, particularly matrix functions such as product management, the responsibilities may be explicit, but the authority is implicit in the role. It’s up to the individual product manager to understand that and not get caught up by the lack of a hierarchical reporting structure with other teams.

In my first PM job, after a frustrating product strategy meeting with senior management, one of my fellow product managers let out the famous line:

Product Management: All of the responsibility and none of the authority!

It was the first time I’d ever heard that line, and that afternoon, I couldn’t have agreed with him more. I had faced my own battles with the CEO over product direction issues.

When the first bullet point of the first slide of your product strategy presentation quoting a well-known industry analyst is brushed off by the CEO, and the analyst called “an idiot in a monkey suit“, you know it’s going to be a rough meeting. And when the CEO regularly plays a game called “If you guess what decision I’ve made about your products, then we’ll be in agreement on that issue“, it’s hard to feel empowered.

But, in the intervening years, I’ve learned a little bit about responsibility and authority and don’t agree with that line anymore. The fact is that, regardless of whether you have a CEO (and/or management team) that “gets it” or not, you’ve got a job to do, and whatever frustration you may be feeling about lack of authority is probably shared by your peers in other teams. So what can you do to use the authority that you do have and be the leader that you must be?

Welcome to my 4Cs of Leadership.

Credibility
Leadership begins with credibility.

credibility: noun. the quality of being believable or trustworthy.

If people aren’t willing to believe you and trust what you say, then there is no way you’ll be given authority to do anything significant.

How do you become credible?

For a PM, the best way is to be viewed as having the most thorough knowledge in your organization of what is needed to help make your product successful. That is what everyone is expecting of you (you are the product manager!), and if you can exceed those expectations, you will have credibility when you speak with people. Some things to put on your “How do I gain credibility?” checklist are:

• Know your product as well as your users know it
• Understand the architecture well enough to know it’s strengths and weaknesses
• Talk to more customers and partners than others in your company
• Collect more hard data about customer and market needs than your peers
• Understand the needs and dependencies of your internal teams (sales, support, marketing, engineering)
• Help those teams in their efforts where reasonable and valuable

Gaining credibility takes time. You’ll have a bit of a grace period when you start a new position, so use that period to get up to speed. Then, continue to work at it and ensure that once you have credibility, you don’t lose it.

Commitment
The second C of Leadership is commitment. The definition I like is:

commitment: noun. the act of binding oneself (intellectually or emotionally) to a course of action

Look at that definition closely. The words are very specific: “The act of binding oneself…” You must demonstrate commitment to your product’s success. In your current job as a Product Manager, have you bound yourself to the success of your product? Or are you just going through the motions and simply doing the job? People want to see that product managers truly care about product success and figuring out what is right and best for their product. If they don’t see that commitment to success, you will quickly lose credibility.

Communication
The third C of Leadership is communication.

communication: noun. the art and technique of using words effectively to impart information or ideas.

No amount of credibility can be retained if communication barriers exist between a leader and his/her followers. Leaders must be able to communicate their thoughts, ideas, visions and strategies clearly and succinctly, and in such a way that those listening are inspired to want to be part of the plans the leader is proposing.

Note that communication is both an art and a technique. Simply conveying information in documents or in rote form is not sufficient to be deemed communication. People need to understand what you are communicating to them and realize why it is important to listen to you.

Put yourself in their position and think about what they need from you. Convey information in forms that those receiving it from you find valuable. This may mean a bit of extra work for you initially — not everyone needs (or wants) to read requirements documents — but once people see you understand their frame of reference, they’ll see the value in understanding your communications. Keep in mind, people are bombarded with information daily, and they triage what they read and what they put aside. Make sure your information gets top priority by making it easy for them to consume.

Once you have credibility with your peers, show commitment to your product, and communicate vision and details clearly, you have the hallmarks of being a leader. But what can truly distinguish a good product manager from a great one is courage.

Courage
Welcome to the 4th and most challenging of the 4 Cs.

courage: noun. to act in accordance with one’s beliefs, esp. in spite of criticism. to have the courage of one’s conviction

The difference between a leader and a manager is the leader’s ability to take risks, blaze new trails, and have people follow him or her down those trails. Leaders can be praised when they succeed, but will be criticized roundly when they don’t.

As a product manager, you are an agent of positive change in your company. Stand up for what you believe is right, but do your homework first and be able to support your positions confidently. Not everyone will take to your recommendations or initiatives, even if you are correct. But, over time change can happen, even in the most conservative or difficult environments.

In companies that are open to change, it is a continuous process. In other companies, it comes in the form of a revolution. Regardless of the type of company you work in, if you want to rise to be viewed as a great leader, then have the courage to take, as Frost put it so well, The Road Not Taken.

The last stanza of Robert Frost’s poem sums things up nicely in my mind.

I shall be telling this with a sigh
Somewhere ages and ages hence;
Two roads diverged in a wood and I-
I took the one less traveled by,
And that has made all the difference

Saeed

Part 3 - “Spidey sense” instincts are good. Hard data is way better

Part 5 - Be an integrator, translator and communicator. Don’t be a terminator 

What do you want to read about?

Hello. We’ve been at this for a couple of months now, writing about various PM related (and sometimes unrelated) topics. And while we will continue posting as we see fit, we also want to hear from you about what topics you’d like us to cover.

Now that may be atypical of blogs, to ask readers what they want to hear about, but being Product Managers, it would be unnatural of us not to ask.

Is there something about Product Management or Development or Innovation that piques your interest? Want to know more about product pricing, positioning, process or partnerships? Any interest in SaaS or Agile? Want to know more about designing demos? Got a burning question you want to ask?

• What would you like to read about?
• Is there anything we’ve written, that you’d like to see more of?
• Is there anything we should stop writing about?

Let us know.

And another thing. Software demos need serious help

Most product demos are really terrible. SEs - at least a lot of the ones that I’ve seen - love to focus on the product features, but forget that they have an audience with specific goals and problems, and the audience doesn’t really care about the software; they care about achieving their own goals or solving a problem.

Why I hate PowerPoint

I hate PowerPoint. I hate what it has done to modern meetings, and I hate the fact that it is expected that one will produce slides for each meeting. Am I being a little strong here? Maybe the verb should be lament. Yes, I lament the dominance of PowerPoint in today’s meetings.