Tuesday, November 24, 2009

Happy Thanksgiving!

For those of you in the United States, I want to wish you all a Happy Thanksgiving this week!

For everybody, this time of the year also marks the beginning of the holiday season, so to all, I will wish a Merry Christmas, Happy Hanukkah, Wonderful Kwanza, Beautiful Boxing Day, Grumpy Humbug Day, and/or Pretentious Wear a Plunger on Your Head Day.

Regardless of what holidays you celebrate, I hope they are everything you hope they will be!

(Ignore this, it'll go away: 7T26M7B7AQP2 )

Monday, November 23, 2009

Career Change: Gaining Product Management Experience

This is part three of a series on making a career change into product management. In part one, I discussed the some of the career paths that lead to product management. In part two, I discussed the change in focus that is a requisite part of becoming a good product manager. Now let's talk about gaining experience!

Get a Mentor!

Much like driving, product management is most often learned by doing. There are a ton of resources available to increase your knowledge (We'll discuss many of them in part 4 of this series!), however, the more experience you can get on the job, the easier your transition will be.

Fortunately, most product managers are overworked and are more than willing to get some help. In addition, as I was making the transition from software engineering to product management, I never found a product manager who wasn't willing to mentor. He gets help; you learn. A win-win.

Your ideal mentor needs to be a good product manager. If you are frustrated with him in your position, he may not be a good person to be mentoring you. That is especially true if many people on the product team are frustrated by him! It will work best if he manages the product you are working on, but that is not necessary.

Structure Your Learning

To the right is the Pragmatic Marketing Framework™ (click to open a larger version in a new window). Pragmatic Marketing is one of the preeminent sources of product management training and knowledge. The Framework gives a guide to what a product manager's job is. I strongly encourage you to enroll in their seminars if you have the opportunity. You will learn a lot!

Even if you don't enroll in their seminar, you can use the Framework as a guide for experiences you should gain. If you've been involved in any portion of product development (anywhere from requirements to sales and support), you likely have experience that overlaps with the Framework. This is good, and we'll discuss how to present that experience in part 5 of the series.

From Here to Product Manager, With a Map! (An Example)

Let's look at an example of how you can use the Framework to guide you. In this case, we'll be a hypothetical engineer wanting to move into product management.

Engineers are very familiar with the whole product development cycle, as they are usually involved in some way from soup ("How long would this take?") to nuts ("Our biggest client's migration went bad, we need you to fix it!"). The earlier and later you can be involved in that process, the better.

The down-side is that engineers are often kept behind closed doors. This is done primarily to protect engineers from distractions and, occasionally, to protect customers from some engineers. Customer face-time is a major hurdle engineers need to cross.

For our hypothetical engineer, the priorities and associated Framework tasks to get involved with are be:

  1. Interacting with customers. Looking at the Framework, Win/Loss Analysis is a great place to start. I would follow that with as much of the Support column as possible.

  2. Understanding the market. If you've been working on Win/Loss Analysis, you have some great insight that can be added to the Buy Personas. You also could have some valuable insight into Positioning. You may not get the whole box for these tasks, but you can provide valuable input to them.

  3. Figuring out the business. Now you are providing help on items like Distribution Strategy, Pricing, and the Business Plan.

Getting "Career Progression" Support

Often, you will need to spend your own time working on this. This is no different than a software engineer reading technical books on her own time. Ultimately, to succeed, you have to expand beyond your nine-to-five responsibilities.

You also need to have the approval and support of your boss. Even if you are working on these things after hours, these activities will take time from the normal office routine. You can't get input from a customer on a win/loss analysis at 11:30 at night.

Again, fortunately, most employers see this type of activity as a win-win. Career progression is critical to employee satisfaction, and your boss won't have to do anything to give you progression. If you are providing more time on the job, then you are also giving extra value to the company.

If your current employer isn't willing to be supportive, then I strongly encourage moving on to a supportive environment before moving forward. If you don't, you will experience a lot of frustration trying to work around that.

Wrap Up

Get a mentor, identify your weaknesses, identify a path to strengthen those weaknesses, get your boss' support, and get to work. Keep track of specific achievements: "Instrumental in closing 10 sales worth $25M" and "Performed 75 win/loss analyses that drastically altered the selling processes and increased win-rate by 8%" type statements are gold on your resume.

Tricks to Get in Front of Customers

As I mentioned before, customer face time for non-customer facing individuals can be very challenging. It is also absolutely critical. As such, I'll end with a few tricks I used to make that happen. These tricks require your boss' support, so make sure you've got it!

  • Meet sales people. Sales people love to bring other product people into sales calls. Your mentor should be able to introduce you. If the sale call is a live visit, Sales will often have budget to pay for your trip. This keeps your boss happy!

  • Present at user group meetings and other conferences. As a product manager, you will need to be able to comfortably present to a group of people. Depending on the specifics, there may be separate budget for this, so, again, your boss is happy.

  • Attend focus groups. If your company does live focus group meetings, ask to be present. Depending on your current role, you can sell this as an opportunity to learn more about your customers so you can do your job better.

  • Manage the beta program. If you can volunteer to run the beta program, you have a great opportunity to interact with customers and learn how they use the product. Additionally, it may save somebody else who is very uninterested in doing that.

Friday, November 20, 2009

From the Intrawebs - November 20

If you find something that you think belongs on this list, send it to me via @SoftwareMaven on Twitter.

Disclaimer: Unless otherwise noted, I have no affiliation with linked properties other than being an interested reader, a happy user, or a potential customer: Nobody pays to receive a link. Any opinions of linked properties are their, not mine. I may or may not agree, but to be on this list I think their opinion is interesting.

Tuesday, November 17, 2009

Engineer Respect

Is this what the engineers you work with think about marketing?

If it is, it is almost guaranteed they feel similarly about product management.

I've experienced this attitude from three different perspectives: as an engineer giving it, as a functional manager trying to get engineers over it, and as a product manager receiving it. Few things will derail product development as badly as this attitude. Complete with this attitude comes the corollaries, "I know the product better than you" and "your opinion doesn't really matter."

If you want to succeed with your product, you must address this, and addressing it takes leadership, not confrontation. No matter how important you say you are, engineers aren't going to change their beliefs until they see how important you are.

Here are some steps you can take to address this attitude. It is not always fast. However, unless you are stuck with the perpetually egotistical engineer (and at most 1 in a 100 are that way), you can prevail!

Your opinion doesn't matter

Acknowledge to yourself that they are right, your opinion doesn't really matter. Engineers are analytical. You need to have real data to be taken seriously. If you don't have real data, get to work.

Know your product

Know your product. Nothing will kill credibility like not knowing your product inside and out. Seems obvious, but I've worked with product managers who didn't and I've seen the problems it caused as they tried to work with engineering.

Each product gaffe that you make (like calling to ask how to use that widget that's been in the product for years) does serious damage.

Avoid business jargon like the plague

The video mocks the term "marketecture" and other business jargon for a reason. If you do have to slip into jargon, make sure it is understood. Never, ever use the word, "synergy".

If you are trying to achieve a result that is greater than the sum of the inputs (e.g. "synergy"), explain it in detail. What is the effect you are looking to achieve and why do you think what you are attempting with achieve it.

Keep the engineers informed on what you are doing and why

Visiting a customer? Let them know what you are trying to accomplish. Asking for A/B testing functionality? Let them know what macro indicators you are trying to learn.

This helps engineers know that you aren't just jaunting around for fun and has the side benefit that you might get very useful feedback that can make your job easier. That is a real win-win.

Get engineers into the wild

The more isolated your development process and organization keeps engineers, the more entrenched the anti-marketing sentiment can become. It can become bad enough that the engineers truly believe that the business exists solely because of them.

Combat this by getting engineers in front of customers with you. This builds empathy for the customer, and, indirectly, for you as the voice of the customer.

Solicit feedback from engineering

Any time you can, solicit feedback from engineering and incorporate that feedback into your product. Engineers do know the product best and may have insights that neither you nor your customers have had. More importantly, this builds trust (really listening to somebody always does), which helps cement the results of the other steps.

Paul Graham contends that it is easier to teach an engineer the business ropes than to teach a business guy to be an engineer. While probably true in general (there are some specific examples of engineers I'd never put in front of a customer), it also propagates the ego-driven belief that engineers have the only hard job in the company and, consequently, the only important job.

You need to help them understand that in most software companies, the primary risk to success for most companies is not technological risk but, instead, is market risk. It is unlikely you will hit a technology hurdle that cannot be cleared, so the product dies (unlike, say, pharmaceuticals, where a drug that doesn't work won't sell). More likely is that you will create a product that nobody cares about, so the product will die, regardless of how awesome the code is. That is the value you are providing.

It doesn't take much to successfully change attitudes: just time and consistency. Good luck!

Friday, November 13, 2009

From the Intrawebs - November 13

This week's picks are up. Thanks to everybody out there who spends so much time writing for my edification!

If you find something that you think belongs on this list, send it to me via @SoftwareMaven on Twitter.

Monday, November 9, 2009

Career Change: Thinking like a Product Manager - It's the Why

This is part two in a series on becoming a product manager. You can find the first article here.

For any number of reasons, you are eyeing product management as a future career. Whether its the innumerable business trips or the responsibility without authority, you know its the path you want to follow.

Congratulations! You are in for a wild ride.

There is a lot you are going to need to learn, much of which will be on the job. Things like how to placate a surly engineer, how to make a customer feel good about your product, how to guide executives to your way of thinking will become second nature to you and the more you have done previously, the easier it will be to assume this new role.

Even before you begin learning those things, though, you have one of the most difficult tasks in your career in front of you. This task is difficult for all fields entering product management, but I think it is particularly difficult for software engineers.

Stop Thinking About Who, What, When, and How.

In the intro to the series, I discussed career paths into product management and their focus (who, what, when, and how). Figure out which you are and consider, as a product manager, the following applies:

Who: You need to relinquish your control over deciding who the right person is to complete a task. This can be disconcerting when you know who the right choice is. Furthermore, it can cause serious friction with other managers.

What: You need to understand the reasoning for the what to build. It can be very easy to fall back into a comfortable place of writing requirements.

When: You need to step back from the highly tactical world of what comes next. Certainly, successful execution is important, but if you are running your product through a Gantt chart, you are missing the strategy that will differentiate your product and bring real success.

How: You need to recognize that your job just got a lot broader. With that breadth can come a feeling of "not getting things done" or disconnectedness after years of intense focus. If you continue to focus on the how, you will miss business drivers that guide your product and you will risk disenfranchising your engineering team by minimizing their expertise and taking away their responsibilities.

Start Thinking About Why!

This is the switch from tactical to strategic. This is understanding where the market is today and being ready for where it is going tomorrow. This is understanding what causes one customer to purchase and another to pass.

Every time you lay down a feature in an MRD, you will need to have data supporting it. Beyond describing the feature, beyond saying how many people will love the feature, beyond comparing competitor feature sets, he data should describe why the feature is important.

Consider the difference:

The product must support features X and Y because 73% of customers say they want it.


The product must support features X and Y because 73% of customers say they want it, including the majority of buyer persona who perceive them as critical points of comparison. These features will reduce the time it takes to close sales, increase out win rate, and strengthen our reception by analysts.

Figuring out the "why" will be the most challenging thing you'll do as a product manager. It will also give you the respect of your co-workers, the trust of your executive team, and the foundation for success for your product.

Start practicing in your next product meeting. Start asking why, and if the product manager doesn't have the answer, it's a great opportunity for you to offer your services to help find out.

The next article in the series will discuss gaining product management experience.

Special thanks go out to Jeff Lash and his blog, How To Be A Good Product Manager.

Friday, November 6, 2009

From the Intrawebs - November 6

Been a very busy week for me, so I haven't had a chance to get the post out I was hoping to. In the meantime, here is this week's picks.