Product Management Musings

The lessons I've learned from Steve Jobs - A tribute

2011-10-09T16:22:00.000-04:00

This week, Steve Jobs passed away. I never met him. I never worked for him. But somehow I felt touched by his loss. I wanted to wait a little bit before I wrote this tribute (there has been a lot written since his passing). I wanted to process my thoughts and try and codify what I learned from him. So here they are, some of the lessons from a great visionary and leader, Steve Jobs:

Have a vision - Steve knew what he wanted and had a vision. Whether it was with NeXT, Pixar, or Apple, he had a great sense for what was beautiful. He knew it when he saw it.
Pay attention to the details - If there was one thing I love about Apple is there attention to detail. Everything matters. The packaging, the material, the feel of the product, how well it works with everything else. I just felt special using their products.
Hold people accountable - Steve was well known as a difficult manager. He would yell and use less than appropriate words in meetings. While many may consider this inappropriate or consider this rough management style, I tend to look at it on the flip side. He had high standards and he held people to them. He didn't let people feel like it was ok to not be your best. It is not ok to not stretch before your means. People will follow you when you lead them to success.
Be mindful of how you spend your time - As Steve's health began to get worse, I read a lot about how he would choose how and with whom he spent his time. He knew what was important and he focused his limited time there. He was the master of knowing when to say "No". This is a great lesson for all of us. Since he past away, I have learned to be more mindful of how I spend my time. Am I making my life better? Am I making a difference? Suddenly watching football on Sunday afternoon's doesn't make much sense.

Some of my favorite Steve Jobs Quotation

”My job is not to be easy on people. My job is to take these great people we have and to push them and make them even better.”
“Be a yardstick of quality. Some people aren’t used to an environment where excellence is expected.”
“It’s really hard to design products by focus groups. A lot of times, people don’t know what they want until you show it to them.”
“Sometimes when you innovate, you make mistakes. It is best to admit them quickly, and get on with improving your other innovations"
“Do your best at every job. Don’t sleep! Success generates more success so be hungry for it. Hire good people with a passion for excellence.”
"Remembering that you are going to die is the best way I know to avoid the trap of thinking you have something to lose. You are already naked. There is no reason not to follow your heart.”

So, Steve I hope that you know that not only did you impact how folks use technology, listen to music, watch movies, but you also impacted how people think and behave. Thank you.

Great vs. Good Product Managers

2011-09-04T14:33:00.000-04:00

In all my years of product management (and being an electrical engineer and software developer) I've started to pick up what separates the great product managers from the good product managers. I've decided to share my thoughts on this today and I'm curious as to your thoughts. Without further ado:

Inspiration - Great product managers know how to inspire the people that they work with. This means inspiring your fellow product managers, your development teams, and your cross functional coworkers. The great product managers are leaders. They know how to endear themselves to others and really be that positive energy that can lead to teams exceeding expectations. They are relentless in their promotion of their products and teams and folks see that and are drawn to them.
Pro-active - Great product managers are always a step ahead. They are already working on the next release and are ready when that request comes. Without being asked they prepare quarterly reviews or highlight market shifts. They seek out opportunities to talk to customers and get feedback. Whenever a request comes in, with very little effort they can meet the request. How many of us, myself included, have had to scurry to create a presentation, business model, etc. when we should have anticipated the request. This is a tough one!
Thoroughness - Great product managers know how to "peel the layers of the onion" so to speak. While the good product managers may use anecdotal evidence or a customer interview to support their position, the great product manager will dig deeper into market research, competitive intelligence, customers support cases, multiple customer interviews, discussions with Sales and support, etc. The Great product managers know how to build a more complete picture of the market problem rather than trying to jump quickly to the feature.

Please share your thoughts?

Let me give you the BOOT! - A real world pricing example.

2011-08-12T21:27:00.000-04:00

So the other day I injured my calf and the doctor gave me this boot to wear. I originally had crutches but after fumbling around with them, I asked for a boot. So as I leave the doctors office and sign the paperwork I noticed that the boot costs $160 dollars. At first I thought "I should be in the boot making business! That's way too much for a bunch of velcro, foam, with a little bit of metal on the bottom"

But then the product manager in me asked the classic question "What value does this boot provide me and would I be willing to pay $160 for it?" We'll let's see here's the value that it provides:

Comfort - Way more comfortable that crutches
Prevents excruciating pain when bending ankle - That's pretty valuable, who likes pain?
Reduces Healing time - by preventing me from reinjuring myself I can get to normal fun activities much sooner

So now I thought to myself "Is the boot worth $160?" and the answer is YES! Also, if you wear glasses or contact lens, think about how much those cost to make vs. how much they charge.

I would also say that perceived value has an emotional side to it. Think about all those Apple fans who have an emotional relationship with their iPhone, iPod, MacBook, etc. That increased emotional tie leads to higher perceived value which ties into a higher price. As you design your product, think about the emotion you want your customers to have!

Kanban - Some Open Questions?

2011-08-08T09:36:00.000-04:00

So this topic has come up some here and there (I remember studying it a bit in my Supply Chain class) and I've been thinking about it and researching it a bit more and I have some open questions about it. So here you go:

Question #1 - Without a sprint commitment, what motivates the team?
The typical answer to this sounds like "The team is excited and aligned to the vision of the product owner so much that they will be motivated to see the team (and company) succeed". I agree...but without a commitment will they be as motivated? Let say for example, I join a gym that is $1 per month. If I go, then great, if not, then I've only lost a buck. Now let's say I join a gym that is $100 per month. If I don't go I'm wasting a lot of money and I'll either quit my membership or start going. The size of the commitment impacts how I act. With no commitment how will the team act?

Another way I started to think about this question was to go back to the roots of Kanban (manufacturing cars...learn more here). When manufacturing cars, a person will stand on assembly line and repeatedly perform the same task over and over again while the cars move down the assembly line. There is a key point here...each worker has a specified amount of time to perform very specific steps. That sounds very different than software development. Also, what motivates the assembly line worker will not necessarily motivate the software developer.

Question #2 - How can you understand your team's throughput when not every story is the same size?
Let's go back to another common question "How will you know if the team's performance is improving?" and the typically Kanban answer is that the amount of time per story will decrease thus increasing their throughput. But here is where I get confused...

Let's once again go back to the origin of Kanban building cars on an assembly line. The worker on an assembly line knows exactly what their task is and will always be and knows exactly how long it will take. That is not to say that improvements cannot be made to decrease the time it takes to perform a task, but rather that there is uniformity in the task. Compare this with software development where stories are introduced to the Kanban team. Some stories may be minor...and if a team gets a string of these stories in a row it will appear to the outside observer that the team is really performing since their throughput has increased. Now, suddenly they get some larger stories thrown in the mix and their throughput drops as the tackle these more difficult stories. Is the team performing poorly due to the non-uniform task size? Imagine if you will that same assembly line worker getting a 4 door family sedan and then a 2 door sports car, and then a 4 wheel drive truck and then the factory wonders why it takes they have a different throughput?

These are just some thoughts....Not sure if they are meaningful to the broader lean/kanban audience...so I welcome answers to the questions above! Please help! I definitely see Kanban's potential value and want to consider it more deeply, I'm just trying to answer a couple of questions, so go easy one me.

Marketing and Schrodinger's Cat?

2011-08-04T14:59:00.003-04:00

Being a former geek (and still trying to retain my geek credentials) I like to watch Through the Wormhole to help me live vicariously through these great scientists. So this is my attempt to combine 2 of my favorite subjects (physics and marketing) and somehow not alienate either the marketing folks who read this and the physics folks (assuming either marketing or physics folks read this blog)

On one of the recent shows they explain the famous Schrodinger's Cat paradox (for those that are unfamiliar with this paradox click here). In this case the cat is both alive and dead and you don't know what state the cat is in until you open the box.

This reminds me a lot of how some folks approach marketing. They don't know if their efforts and dollars are effective because until they "open the box" on the results. But many of them don't bother to even open the box and think that they are succeeding!

So this ends my poor attempt at comparing quantum mechanics and marketing...but for some reason I want to continue typing away.

So don't forget it isn't marketing unless you have a goal in mind at the beginning and that you measure yourself against that goal. After you measure your results you now know whether or not achieved your goal, but one question still remains...Why? Why did you achieve your goal? (which is different than "What did you do to achieve your goal?"). You have to think about both.

For example, let's say your goal is to get more paying customers and you determine the best way to measure that goal is to compare the number of paying customers you get this month vs. what you got last month and the same month 1 year ago. So far this is pretty easy! Let's say you decide that in order to achieve your goal you will:

Drive more people to the purchase page
Have a 1 month special discount

Great you now have your tactics down. At the end of the month you look at the numbers and you have achieved your desired results. You can point back to your tactics to help you answer the question about what you did to achieve your goal. Great! Now ask yourself why did more people visit the purchase page and why did they decide to purchase? What factors drove them to convert? Suddenly the answer is not as clear...it could be any one of the following:

The lower price
The features of your product
Dissatisfaction with their current provider

Or it could be any combination of the 3??

Once you understand the why it can impact your tactics in the future to help you refine your marketing.

Product Experiments

2011-07-06T22:41:00.001-04:00

Lately I've been thinking about business plans and product launches and how product managers can validate many of the assumptions that are made about their products. It is rare that a product manager can really know/survey potential customers before a product is launched or before making a major product decision. We all make some assumptions, is there a way to minimize the risk that we are wrong?

Some typical product assumptions:

Price elasticity of demand - This boils down to how price impacts demand. Should you go with a low price strategy or justify a higher price since you have a differentiated product. How will changing the price up or down by 10% impact quantity demanded?
Market Size/Potential - We can always assume that everyone is interested in our product, but sometimes those assumptions aren't true. This is especially difficult to assess when your market size is dependent on the adoption of a broader platform on which your product is built, etc.
Most Important Features - Often times product managers think they know which features will be used most often. The surprising thing to consider is how the feature is used with other features or what other features are being used to an increasing degree.

So how can a product manager mitigate the risk that one or more of his assumptions will prevent the product from living up to its full potential? Here are some ideas:

Experiment with pricing - One way to do this is to conduct a short pricing experiment where the price is increased by X% for 1 month and then decreased by 10% the next month. Compare and contrast the demand changes, if any. Another idea is to offer every other customer a different price (if possible) as this will remove the seasonality component of demand changes.
Try a Beta - Start with a beta and learn from that and then launch the real thing. This is a common method to help refine the feature while minimizing the likelihood of releasing something that is not very polished. You can even turn your "beta" into a special event by limiting who can participate and making those that you select feel special by giving them a sneak peek.
Offer the feature to your high end customers - Perhaps you have different versions of your product (e.g. Basic, Pro, Premium). Offer the feature to the premium customers as a sort of beta and then once the kinks have been worked out (and you have hopefully derived some additional revenue). For example, you could offer a feature in the high end version of your product and use those higher margins to recoup your expenses in building the feature. Once you have recouped the costs, consider moving it to the lower end version of your product to increase adoption and differentiation in that version of your product.
Include a Feedback button - Be prepared to get some constructive criticism :). I would recommend personally replying to every single one of them to encourage a dialogue.

Oh well...just some thoughts for today....I'm already thinking about my next blog post so that's probably a sign that I've exhausted my thoughts on this subject :)

Enjoy!

Competitive Advantage vs. Competing

2011-05-29T10:20:00.002-04:00

So I'm going to borrow a page from MBA days (and of course, Mr. Porter) and discuss competitive strategy today. Everything always boils down to how do you create a long term sustainable competitive advantage and then manage to keep it. Many times, product manager just want to compete rather than build a competitive advantage.

Whenever I look at building a feature or assessing a competitor I rate/rank the feature against the following 4 criteria:

Valuable - Is the feature valuable for your customers/prospects?
Rare - Is it rare or common in the marketplace?
Costly to Copy - If you were to build the feature, would it be easy for competitors to mimic you?
Easy to Substitute - Can the feature be substituted with another feature, thus eliminating this features importance?

You should apply these 4 criteria to the target market segment for your product/company. For example, 8 cylinder engines are Rare for 4 door family sedans, but not so rare for large SUVs. If you start with your company/product and create a VRIN matrix of all of your features and then one for your competitors you may find some nuggets of information such as:

Your product has no long-term source of competitive advantage
Your product is well positioned vs. the competition, however, this is likely short term as it is easy for competitors to catch up
Your product has a lot of features that are not valuable to your target market, but are valuable to another market segment.

As you and your competitors add new features add them to the matrix and put a date of launch. You may find that by focusing on when a feature is launched you may be able to determine trends (e.g. your competitor has been building a lot of features lately that are focused on a particular market segment). You will be prepared next time an executive asks you for how you compare to the competition.

Another analysis technique I have used is Kano analysis to help determine the type of feature. For more information on Kano analysis click here. The uniqueness of Kano is that it asks the negative question (i.e. How would you feel if the feature was not present?) in addition to the positive question (i.e. How would you feel if the feature was present?). The negative question allows the product manager to determine which features are "exciters" vs. "expected".

So as you think about competing in the market, don't forget to think about building up your competitive advantage!

Why companies fail - A lack of focus on the "micro"

2011-05-28T09:48:00.002-04:00

Much like physicists are trying to create a grand unified theory of all physics to explain all the various forces and particles, I started to think about a unifying theory about why companies fail. Now I know what you are thinking, there are many reasons and coming up with a single reason is silly. Don't worry I thought the same thing. But I didn't give up.

There are so many books out there such as "Innovators Dilemma", "Good to Great" and "Blue Ocean Strategy" that provide all sorts of reasons why companies don't achieve their potential. I think all of these books focus on the "macro" side of things. Things like corporate strategy, corporate focus, etc.

But the reality is that the "macro" result is the sum of many "micro" interactions. That is the topic of this blog post...what creates the types of negative micro-interactions that cause companies to fail. At the end of day companies are run by people and people interact with each other and it is these interactions that are of interest. This topic reminds me of Patrick Lencioni's book "5 Dysfuntions of a Team"

So I'll start with this hypothesis and then we can pick it apart.

All negative micro interactions are driven by the employee putting their needs before the companies need. So let's ask Why?

Why - Because I have a desire or need that supercedes the needs of the organization
For example - I will not share my opinion when asked because I fear for my job.
As a result - They attempt to rationalize this disconnect by convincing themselves that there needs are aligned and that it is ok for me to not give my true opinion when asked.

Or let's try this one:

Why - Because I have a desire to advance my career at the expense of the organization
For example - I'm going to get "buddy buddy" with key influencers in the company so that I can become their "Yes" men in order to get the next promotion.
As a result - People have a tendency to hire/promote folks like themselves. Employees will see this "favoritism" and complain about politics and morale suffers.

Now multiply these interactions be every time they occur with all the employees in your company. Healthy companies spend time focused on the "macro" and "micro" in order to improve.

What are your thoughts? I wonder if we can go look at companies that have failed and see if we can characterize their cultures and draw out key indicators of companies going in the wrong direction. It would be like "Good to Failed - Why companies fail" the exact opposite of most books that describe how to succeed. If you think about it, it actually make sense...it is easier to drive consensus on what is bad vs. what is good just like it is easier to say and agree on what "smells bad" vs. what "smells good".

Oh well...enough rambling for a Saturday morning.....

Why I turned down an interview with Google

2011-04-30T10:13:00.001-04:00

This blog post is a bit more personal than my traditional blog post, but I felt it necessary to help me get my head around why I politely declined an opportunity to fly out to Mountain View and interview at the Googleplex.

First of all, it happened so quickly! They found me through my LinkedIn profile and emailed me about a job opportunity as a Lead Product Manager. Wow! I was flattered. I had a 45 minute phone screen with the recruiter and it went really well...mostly questions about my experience, managing people, and education. Nothing too hard or anything. I really did not prepare for it, I was just myself. The one question she asked that caught me off guard a little bit was "What is the most important accomplishment of your life?" If you want to know my answer, let me know. Anyways, she said I fit the mold of the type of product manager they look for and I sent her some information and we set up a phone screen for Wednesday (just 3 days later).

I didn't really prepare or the 2nd phone screen either. It pretty much went like this:

5-6 minutes talking about my experience
20 minutes talking about how I would improve a product that I really liked
4-5 minutes for questions I had for them

It seemed very rushed and although I answered the questions well (at least I thought), it just seemed rushed to the point where I didn't feel comfortable about how the interview went. Oh well...I thought..

Next day I get an email that says that they really liked me and want to fly me out for an in-person interview. Wow, that was cool...but then my mind started racing...was I ready to fly my entire family out there if I got a job offer? I didn't want to waste Google's time or mislead them if there was a very low likelihood of taking a job given my current family situation. I really struggled...I didn't want to look back and regret that I had not gone out there...but I also wanted to be honest with Google and with myself. To thine ownself be true!

After spending some time thinking about it, I called to politely decline for the following reasons:

Fit - The job wasn't quite a good fit for my skills/interest. I love research and market analysis and this opportunity did not lend itself to that as much. I like sizing markets and public market launches. So it just wasn't the ideal fit.
Career - At this point in my career, I want to manage and lead people and take that next step forward in my career progression. I wasn't quite ready to start over at a new company. Plus I like where I am now.
Family - My extended family is nearby and at this stage it makes more sense for me to stay near them.

We had a positive call and you never know what the future holds!

Does Marketing Create Value?

2011-03-31T21:43:00.001-04:00

This blog post rambles a bit...bear with it :)

So I read a tweet from @NCStateMBA (where I got my MBA) that read "Marketing is all about creating value. Our Marketing Management MBA creates value for tomorrow’s business leaders". When I first read the tweet, the 1st sentence really struck me. Is marketing all about creating value?

So I have to admit, I am a bit biased since I'm a product guy...but the more I thought about the question the more I realized that marketing does not create the value, but they can participate in the process.

Pick up any marketing text book and they talk about the 3C's and 4P's. More often than not, a marketer will know how many customers the product has, and what the price is, and what the latest promotion is, etc. But they may not know the WHY! Why do your customers by your product? What need do they have? What are their selection criteria? What price would they be willing to pay? In fact, some marketers may not even care...they may be tasked with generating a set number of leads and that's about it.

I've recently read links\tweets that encourage startups to focus on the product and let that lead the way in creating customers. The product is the value. If you have a product that solves an unmet need and does so in a compelling way...it may not need that much marketing (if any). Your customers will spread the word. I'm willing to be if Apple did not have a single iPhone commercial, they still would be quite successful.

So is Marketing all about creating value? - I'd so in a perfect world they participate in the process, but they definitely don't create the value. I'd say the product development team creates the value.

That being said, I do think the NC State MBA does create a tremendous amount of value for those that get it and is really awesome. I've worked with a lot of MBAs from those "blue" schools nearby and I'll say that I'm glad I went to NCSU. One day, I wish I could go and get an MBA from one of those schools just to see what all the fuss is about, but I'm not sure I want to get saddled with those student loans. How's that for ROI!

P.S. If one of those blue schools is reading this, I'm willing to go there for free and blog\tweet about how wonderful your school is :)

More Product Management Resources

2011-02-21T23:22:00.002-05:00

So I've done a couple of blog posts (here and here) on resources that I like to use to help research the market. Here are some additional resources that I use and would recommend in conjunction with my previous blog post.

Google Scholar

Every once in while I am researching a topic that may lend itself to some academic research. The best part of this type of research is that the authors are unbiased. However, it may not work very well for more recent business topics. I just like to keep this as a source in my back pocket.

Wikipedia

Obviously, I don't always believe what is on wikipedia, but it can be a source for additional research. I like to read the links in the "Further Reading" and "References". It's contextual helpful content.

Quora

I just started using Quora. I'm not sure how I feel about it, but it does seem to have content on there that can be helpful. Especially for very nascent or non-mature markets

Google Images

Often times I'm looking for articles or data to better understand a market forecast or market players. The images search typically helps point me to the right articles that have the richer market insights via some pretty images.

Are there any other tools that you use? Care to share?

Understanding your Customers Purchase Criteria

2011-02-07T22:38:00.001-05:00

A lot of times product managers are so focused the details of the features that are being built and how customers will interact with them that they forget about how customers become aware of and purchase your product. What goes through the mind of a shopper when they are making that decision to purchase.

This reminds of me of what many of the top consumer goods companies do to understand their consumers. They set up a grocery store (fully stocked and functional) on site and watch consumers make their purchase decisions. This is probably why all the kids cereals are on the bottom shelf and all the ones with fiber and oats are at the top :) After they make a purchase decision they interview them and really dig into the psyche of the customer.

How many of us have had a competitor launch a whiz bang feature that you have never even consider? For example, in the early days of LCD TVs no one ever heard of 60Hz or 120Hz, etc. Now it's like an arms race with this stuff (just read the latest Crutchfield). A company made it a purchase criteria through its heavy marketing and then everyone had to follow suit. I'm willing to bet 99% of consumers could not tell the difference between 120Hz and 240Hz. The problem with this feature is that it is easy to duplicate, so any competitive advantage is fleeting.

So as many folks approach you about a feature, always keep in mind your customer and how they decide to make their purchase and don't think that it doesn't change. These criteria change!

Slide Share for Market Research

2011-01-22T12:46:00.000-05:00

So a couple of weeks ago I blogged about how I use twitter to make my job as a product manager easier (Check it out here). However, there are some deficiencies with Twitter which I will briefly describe and then I'll dive into another tool I have used (and continue to use) SlideShare.

Twitter Challenges

Perhaps It's just me, but I don't really find twitter for researching topics outside of the folks I follow. For example, If I'm doing research for "online marketing" on twitter...the results are just not that helpful. If your network on twitter is not strong in an area of research you have to go find folks to follow and it just isn't quick or easy enough to identify experts and move forward. I want my research on the quick!
The strength of twitter being only 140 characters, can also be a weakness. It can be harder to determine if the link is meaningful enough for me to click on. I find myself clicking on shortened URLs trying to find something and it's just not a good use of time. This is where search is easier in my opinion.

SlideShare, on the other hand, has rich content and is easily searched. It's a great source of secondary market research. You don't always have access to analyst reports, etc., but you can find some content online at SlideShare. The slides are great and very visual which, as a product manager who sometimes needs to convey complex topics in an easily understood fashion, is very valuable. There is so much great content there, I can easily spend hours. Check it out here.

Understanding your Product - Product KPIs

2011-01-16T21:16:00.000-05:00

Many times, Product Managers focus on the launch of the product and then they are off to focusing on the next product or the next feature. They don't realize that the launch of the product is just the beginning. It's time to understand and validate those assumptions you made when building the product. Do you really understand how customers are using and interacting with your product? Do you understand how the product impacts the customer?

Here are some key metrics to measure and ideas to help you better understand your customers:

Think about Measurement when Building - Often times we are so focused on building the features, we don't think about how making sure we can measure and understand the product's usage afterwards. It's OK to pay a little bit of a cost penalty to make sure you have the data you need to inform your future decisions and your management.
Weekly KPI Dashboard - Collect the data on a regular basis. I prefer to aggregate that data in Excel with a sheet called "Dashboard" that has a visual display of several graphs while all the other sheets contain all the raw data. There are several benefits to collecting and knowing this data. For example, any time an executive asks me about the product's usage I typically know the answer right off the top of my head while other product managers are left scrambling to find this data. While you may have data warehouse systems or analytics packages that help with this, I prefer using them to store all in the information in one place. Collecting and aggregating this weekly is one sure way to stay on top of what is going on with your product! Use that data to drive conclusions!
Talk to your Customers - Ask your customers. I know that sounds simple, but too many product managers are not talking to their customers. What problems do they face in general? Or using your product? What features would they like? Why?

Let me know what you think about these ideas...feel free to post a comment.

The 3 A's of hiring

2011-01-14T13:29:00.000-05:00

So I've done my fair share of evaluating employees and hearing about how others determine who to hire. I've heard one manager list out what he looks for in a potential employee and I thought I'd pass along with my own perspectives. So here they are, the 3 A's of hiring:

Attitude - Does the employee have the right attitude? This is very difficult to measure in a short interview. Here are some techniques/ideas that you may find helpful.

I would suggest focusing on difficult or challenging situations and probing deeply into what the candidates initial thoughts facing that situation and how they handled it. This line of questioning can also help you determine tHe emotional awareness/intelligence that the candidate possesses.
Another area to look at is at their LinkedIn recommendations. Does the candidate have any recommendations and, if so, do they reference their attitude. Obviously these should be taken with a grain of salt, but look for common themes across several of them.
How does the candidate carry themselves in the interview. Are they smiling and actively listening? Are they prepared? Nothing turns me off more than a candidate who has not done their homework. Have they read about your product/company and, if possible, used it.
One interview question I read recently (click here for top 2010 Interview Questions) was "You just inherited a pizzeria, what is the first thing you do?". I think this question can really help gauge how a person would approach a problem and what their attitude would be.

Aptitude - Can the employee adapt to change and succeed? How well can they learn? I can't tell you how many jobs I've had where I have gone back in time and looked at the original job description and realize that what I am currently doing in that same job is totally different. Situations and environments change, is the candidate comfortable with that. You can ask questions during the interview about their experiences with change and learned a new skill and how they and others dealt with that. Do they invest in learning and can they adapt quickly to change?
Ability - Do they have the skills to even do the job? Have they done it before? Can they speak with specificity on what they have done?

I can't tell you how many times I have interviewed someone who claims to have written a business case and then the more I probe, the more I find out that someone else wrote the finance section, someone else wrote the strategy section, etc. If you are looking for someone with a great deal of experience they should be able to list out a litany of examples.

These are 3 criteria that I have started using to help me identify and rate candidates. There are many more such as team fit, etc. that can be used...but I like these...

"Growing" your team

2011-01-08T09:03:00.000-05:00

No, I don't mean how to make your team bigger by adding more people. I mean how do you get your team to grow as a team. How do you get them to trust each other and constantly strive to be better? Of course the first thing everyone always says is "Have you read 5 Dysfunctions of a team?"

But I wanted to present some of my personal observations both when I managed people and now as part of a scrum team. Here they are:

Treat individuals as individuals - Folks are at different levels and places in their careers. Some are seasoned veterans who have stepped up and are leading the team, while others are followers. Not everyone is the same and no blanket rules apply. If someone has a particular strength try to accentuate it and improve their weaknesses. Who have to trust your team and guide them. For example, in one of my previous jobs I hired an information architect/technical writer who was very skilled. Rather than try to tell him to do this or that, I worked to give him the tools and guidance he needed to succeed. I let him teach me more about his style and work and then adapted my style to his. This technique really worked!
Always Raise the Bar - Challenge the individuals on the team in different ways. As they grow in their capabilities, continue to raise the bar. For example, let's say you have a natural technical leader on your team who was unable to influence the team on a particular matter. Use this as an opportunity to brainstorm and discuss what happened and how it could have been differently. When you wait to discuss an opportunity for improvement you fail to raise the bar! I think sprint retrospectives are a great opportunity to be transparent, but the team can easily fall into a routine of only highlighting items outside the team for the challenges. For example "The business does not know what it wants" or "The server is not working". You have to recognize this and look to challenge the team to understand how they can participate in the solution.
Be transparent - Constantly share your feedback, but also expect and embrace feedback. I have worked with a lot of folks who are so reserved you never know what they are thinking. I have found these folks so hard to read that they don't motivate the team since no one knows where they stand. This is easier to say than do.
Enjoy Yourself - Too many times it's easy to get caught up in a moment or are frustrated about a particular person or difficult goal. Enjoy what you do and more importantly enjoy who you work with!

Just some thoughts and experiences...

How I use Twitter to make Product Management Easier

2011-01-02T15:55:00.000-05:00

The rise of social media has really revolutionized the tools I use for my product management duties. Over the past several months I have been using Twitter to really help make my life a little bit easier. Here's how I use Twitter and related tools:

How I use Twitter

Listening to your customers - I like to see what our customers or prospects say about us. Do they like our product, are they complaining about a feature, are they happy about a new feature launch, etc. Just watching the tweets helps give me a feel for how some segment of our customers are responding. Often times, I read a tweet and forward it to the appropriate team/person. For example, if someone tweets about the great service they receive, I take a screenshot of the tweet and send it to the support team to give them some kudos.
Listening to your competitors and their customers - The first thing I did when I installed Tweetdeck (see more in the Tools section below) was to add columns for searches for them and I started to follow them. Now I know when their customers are complaining, when the announce a new feature, what tradeshow or marketing event they are going to, etc. I get to see how their customers are reacting to them and all of this happens in real time. I typically check out tweetdeck on my phone whenever I have a free moment, just to stay on top of it. You have to be careful to not check it too often or it will suck up too much time :)
Gather Market Data - This is really cool! Before twitter I used Google and it just wasn't effective...It took forever to get through the noise of all the search results. Often times I would click a link and the content wasn't helpful and then have to go back to the search and it just took forever. Now I just add a column in Tweetdeck with some keyword (or hashtag) I am looking for and the research just comes to me! With only 140 characters it is easy to quickly digest the nuggets of information and then find the right content. Because the content comes from people like myself, it is often relevant and helpful.
Follow the right people - Easier said than done :). Often times I look to follow key employees of my competition, bloggers who seem to have a lot of good information, and of course employees of my current job. I try my best to use this stream of content to help augment my other twitter streams with content that can sometimes provide more context.

Tools

TweetDeck - This is a great tool of aggregating a lot of twitter content in a customizable fashion. I know folks who use HootSuite which is a great tool as well. Check it out here.
TwitterVenn - I played with this tool a couple of times. It was kind of nifty but a bit slow. It provides a venn diagram that shows any overlap between tweets with same terms in them. I would recommend playing with it for a little bit by clicking here.

So if you have noticed I'm not really engaging in a two way conversation with my customers. You might be thinking that takes the "social" out of social media. You would be correct. Depending on your company this may not be desired (some companies have folks whose job it is to monitor and respond to customers). For the time being I just use it to listen and if I find something really useful I can always retweet it.

Thanks and have a happy new year!

Owning Product P&L

2010-08-15T15:42:00.002-04:00

This is often a highly debated question in the product management community. Should product managers own the P&L of their product? The answer is simple, it depends!

Here are some of my observations on the subject:

Authority - Most product managers don't have the authority to truly own P&L. Most of us don't have the product development headcount or other associated costs under our budget. Many product managers don't want that authority.
Time - Many Product Managers are torn between the day to day work of product development, supporting marketing, sales enablement, etc. that monitoring product P&L falls to the wayside. We just assume that the pricing is "good enough" or that someone else is monitoring how much our products cost to develop, sell, market, or support.
Organizational Structure - Does the organizational structure lend itself well to a single person owning the P&L. I have seen this work when the company is organized into distinct SBUs or SBUs. The General Manager of that SBU would own P&L, budgets, etc. and their P&L would roll up into the companies P&L. Ask yourself, who owns the P&L for your product. It's ok if it is not you, as long as someone does.

Recommendations

Create a basic excel dashboard that has the basics and some charts that can printed out on a single page. I use a 3x3 grid for a total of 9 charts that monitor things like bug count, internal costs breakdown, revenue, key usage stats, other costs, etc. Having a dashboard like this goes a long way when someone asks about your product and you can instantly respond with a detailed dashboard. How many of us have had to scurry to find information when someone asks. Be Proactive!
You may not have access to all of the data you need to create a 100% accurate P&L. That's ok. Approximate. It's ok if you call your P&L an "Estimated P&L". Guess, ask, do what you can. Most of your assumptions are probably not too far from the truth and if they are someone will inform you otherwise :)
Share your dashboard. Many products may have a weekly team meeting. Perhaps at the first meeting of the month you can share your estimated product P&L for the previous month. Just seeing it goes a long way!

Just some thoughts. Let me know what you think!

My Experiences with Great Leaders

2010-08-10T23:33:00.000-04:00

In my career, I've noticed it has become easier and easier to separate the great leaders from the average leader. I've spent some time thinking about what traits they had in common in an effort to learn from others.

Here are some traits of great leaders:

Collaboration - Great leaders understand that there are always competing priorities and product development requires the alignment of many disparate teams. I've noticed that they always have the ability to truly partner with others rather than throw dependencies over the wall and down the hill so to speak. Who wants to be on the other end of that? No one! Great leaders know that and work to partner and collaborate on planning and execution to drive results.
Respect - Great leaders earn the respect of others. Don't be fooled by titles, titles don't mean you have earned any respect. The best way I've experience to earn that respect is to deliver results. Say what you are going to do and do what you said you would. Communicate and listen!
Level Headed - We all hear about the famous CEOs who bang their fists on tables and cause a lot of angst among the whole company. Or the project manager that snaps at someone who misses a deadline. Great leaders know that there is a bigger picture and how you handle tough situations says a lot of about your character.

Every time I write a blog post like this I feel like I'm saying the obvious, but then I read other professional blog posts and I always think that their content is also pretty obvious. So I thought I'd also include some of these observations and learnings.

Enjoy!

Never forget the product demo

2010-08-01T22:53:00.001-04:00

Sometime we build great products that don't demo as well as they should.

Here are some thoughts I have about the demo:

Understand your product - I know this sounds pretty basic, but you would be surprised how the lack of preparation can quickly become apparent. Know your value proposition! You have to have objection handling down pat, you should know where you are different from the competition so that you can hit home some key points. Be prepared to answer pricing questions. Walk through the demo both mentally and with the product. Practice, practice, practice!
Understand the demo viewer - Most of these viewers (depending on where you are in the sales process) are either getting an introduction to your product and trying to gauge/compare the value of your product vs. the competition. They are typically not interested in every single detail of your product. I typically like to get to know the demo viewer a little bit by asking them what they do and what they are interested in learning about. Is the viewer the key decision maker, an influencer, the user, etc. Tailor the demo to the demo viewer. As a product manager, I also like to inquire about the viewer's perceptions of the product. What do they like and not like? There is a lot of information to be found in these nuggets of information.
Build a product that demo's well - Sometimes products are too complicated with bells and whistles that can confuse someone who is looking to make an initial impression about the product. It is as if your product has all the features of every power user, but it somehow can't convey its value to majority of non-power users. For example, instead of just a plain "Open" option, you can add an "Recently Opened" option. This would make the demo pretty easy and minimize steps that waste precious time. Also, be aware if you need to incorporate some dummy data? Be mindful, of how credible the data looks and how well it will look when demo'd.

Just some thoughts...any tips from my readers?

Competitive Analysis

2010-07-11T11:35:00.001-04:00

A lot of product managers jump at the chance to take a look at the competition and attempt to glean information to guide the product roadmap. Here are some of my experiences:

Intelligence vs. Analysis - Many new product managers will just gather information and present it to the executives. This is competitive intelligence. This is only the beginning. The analysis part of the equation involves deriving meaningful conclusions based on the intelligence.
Defining your competitive set - This is often times glossed over. Who do you think your competitors are and what do your customers think? A good idea is to monitor your win/loss analysis for this information. Also, if you want to move into a new market segment, you may want to start including those competitors as well in your analysis. It may give you some insight on when you are ready to compete!
Quantitative Analysis - Both types of competitive analysis have a lot of value. I have used a weighted VRIN analysis giving each feature a score of importance and competitive differentiation. I value the "V" a bit higher than the "RIN". I then score each competitor on a 0 to 1 scale (think harvey balls) and then derive a score for each competitor. This is helpful in determining where you stand relative to your competition. This is the "You are here" on a map. While this may seem a bit heavy on the Intelligence side of the equation, it is not. The weighting of the VRIN values comes from understanding and analyzing your target market segment. It is a bit more qualitative.
Qualitative Analysis - Once you have done the Quantitative work. It's time to look at where competitors position themselves. My favorite tool of choice is a perceptual map. These are especially helpful if you can compare snapshots in time. Do you see a competitor moving in a particular direction relative to historical information? Is there an opening for you?
Don't Blindly Follow the Competition - Sometimes the competition is just as clueless as you are. Some competitors like to develop a lot of features without understanding the target market and their core needs. This "blanketing" of features is in the hope that enough of their target market is pleased by enough of the features for the work to deliver an ROI. If you analyze this type of competitor it is easy to fall into the trap of thinking that the market is heading in a particular direction because this competitor is building a specific feature. Remember, sometimes your competitors don't always have strong research, so don't be too eager to follow them.

There is a lot of information here and I blogged this as a simple introduction...more to come soon I hope!

Pricing your products - Some Key Players

2010-05-25T10:44:00.012-04:00

Pricing - It's one of the hardest challenges that face a product manager. There are many typical pitfalls you have to carefully negotiate depending your company. This post is not about how your price your feature, but rather about getting to a price.

I'd like to share a couple of that I have had to deal with in my past:

The Finance Folks - Your most important friend - The finance team is your most important ally, that is until they figure out how much your product/feature cost to build and then just add their desired gross margin target to it and tell you what the price is going to be. Ultimately with many small companies, it is the finance team that really drives the pricing to ensure proper company valuation and key metrics. My advice to you is simple, partner with Finance and work with them. They can help you learn more and if they don't "bless" the pricing, the pricing will not get approved.
The Sales Team - Listen Carefully - The sales team is typically the most connected with customers, they understand the nuance of pricing including how the buyer and user personas will react to pricing. They can help guide both business model and pricing decisions. But tread lightly, sometimes it is Sales' best interest to have as low as price as possible. Understand that profitability is not always their most important goals, sometimes the lower the price the better. This is especially true if they are used to selling a non-differentiated product.
The Competition - Be Wary - First and foremost, know your competition! What are their target markets and key customers and how does their pricing "match" their goals/markets. You'll need to understand how your proposed pricing fits in the market in a way that can help differentiate your product. Also, be mindful of the "rivalry" of your market. If the market is very competitive and crowded, be careful how your pricing will cause your competitors to respond.
The Brand - Be mindful - Pricing causes pretty strong emotions. Do you want to be the low price product (e.g. Dell) or more niche and differentiated (e.g. Apple)? Think about the emotion that you want your prospects to feel when they see the price for the very first time. Price is perhaps the most powerful emotion generator and plays a major role in defining your brand. Be mindful!
The Reality - Leadership Time - You are going to have balance many differing and competing "forces" and opinions. You will not please everyone. Everyone is a cook and you have to somehow run the kitchen and create good food. Realize that you will have to cooperate and collaborate. Time to put your leadership skills to the test and listen!

Good Luck!,

Peter Ghali

Target the Customers You Want!

2010-02-06T15:14:00.004-05:00

I've been doing some recent roadmap work (You should continuously update your roadmap!). In many cases the product your company offers targets more than one market segment. How do you meet the needs of all your customers? Here are some ideas/tips:

Understand how the market is trending. How our your target markets evolving? For example are your users trending towards increased sophistication or starting to desire an easier solution to use? Is the pace of the change in your target market segments fast or slow?
What is your release schedule? If you have very frequent releases you can spend more time worrying about the needs of your current customers in your next release. If your release schedule is much longer, you'll need to really understand where the market is headed and try to "lead" the market (much like you have to lead a moving target when shooting at it)
Think about how you can develop a feature for all of your target market segments. For example you can build a feature for your "power users" and then in the next release you can educate your "average" users and provide them a simpler/easier to use version of the same feature?
Think about monetizing your investment. Perhaps your "power" users are willing to pay for a feature they find valuable, but many of your "average" users may not find that feature useful? Perhaps it is the other way around...your "power" users may expect the feature as part of the product and are unwilling to pay for a feature that your competitors offer for free. However to your "average" user, they may be willing to pay to use it.
Look at where your revenues/profits come from - Is your product revenue trending a certain way by market segment. Perhaps your "power" users account for a small percentage of your customer and large percentage of your profit/revenue? How will that affect your decision to target the right market segment?

This is a pretty complicated subject...just some thoughts on how you can Target the Customers You Want!

Keeping Your Product Management Job

2010-01-11T22:28:00.001-05:00

The Positive Leader

2010-01-04T13:27:00.004-05:00

So a key lesson I learned this past year was to try and be more positive. I often times focus on areas for improvement with our execution to the point of not being as good of a leader as I can be.

So here are a couple of things I do to try and be more positive

Opportunities present themselves to focus on how much has been accomplished. While the obvious one is a sprint review, I like the longer term of the annual or half-year review. I like to look back and ask myself "At the beginning of the year where was our product vs. where it is now". Doing that definitely gives me a sense of accomplishment and focuses more of my energies to making the following year better.
Take your mindset out of the very short term that frustrates you and focus on how it will work itself out over the next week or so. Trust your team to work through it!
Switch gears a little bit to get our mind off of something. I like to work on several things at once, so a switch to something more interesting or fun and can help me refocus a bit.

You have to remember that your mood and emotions are contagious. Be a leader and be positive. Don't sugar coat, don't be blind to areas of improvement...be constructive and move on to the next challenge!

The Art of Meetings

2010-01-02T14:33:00.008-05:00

So this is a new year and while I don't like New Year's resolutions, I do think it is important to think about being more efficient with your time. I like to ask folks, describe your typical work day...for many folks the days are filled with endless meetings. So many meetings that folks bring their laptops to work during the meeting because they can't do their jobs while the meetings pile up.

So here are some of my tips for running a more efficient meeting. Obviously these rules vary a litttle bit depending on the type of meeting (e.g. project update, decision making, communicating, etc.)

Use an egg timer - The loud sound it makes will wake everyone up and keep everyone on time. Discipline is the name of the game here. I had a professor once who used one for our presentations. Needless to say after the first round of presentations they all suddenly were done early or on time. Pavlov at its best!
Start on time - The purpose of this is two fold. One, starting on time makes its easier for you to finish on time. Secondly, it helps instill a sense of discipline. People will start to feel embarassed when they walk in late. They will realize that your meetings are different. If they continually come to your meetings late, let them know in a private conversation that this is hurting the meeting and their presence on time is helpful. If it continues, stop inviting them.
Help everyone be prepared - 90% of being succesfull is setting expectations. Use an agenda to set those expectations with key inputs and outputs clearly defined. By defining inputs you are letting the attendees know what it is needed from them before they come to the meeting. The Agenda will describe what happens during the meeting, and the outputs describes the success criteria for the meeting.
Note who is not prepared - Let them know that you noticed that they weren't prepared. Also let them know how important it is for folks to be prepared in helping drive towards the output. Be tactful. If they continually aren't prepared, don't invite them.
Finish early - This is the MOST important rule. People will leave your meeting with "free" time. They will leave feeling they accomplished something and with the illusion that they have more time.

Remember, be tactful and artful. There is a science and an art to running meetings. Know when to apply each side of the equation to make your meetings more successful. Here is another helpful link.

Accountability and Scrum

2009-12-18T20:37:00.004-05:00

So this blog post is all about the core question of who is accountable for the team's execution of its sprint commitment.

We all know that "product owners" are the single wringable neck for the backlog. He/She makes the final call regarding the prioritization of the work for the team. The Scrum Master is responsible for making sure the team is following Agile\Scrum best practices especially at daily scrum, sprint review, and sprint retrospective.

This core question of execution responsibility is especially complicated because:

Teams are often cross functional (developers, QA, UX, etc.) and each individual has their own functional manager. You can't make the functional managers responsible for the team's performance since there are likely several of them.
I struggle with suggesting that the scrum master be responsible for the teams commitment as he/she may not have the authority in the organizational strcuture.

So now that we have discussed the question, let's discuss a possible solution. My suggestion is simple:

Make everyone on the team except the Product Owner report into a single manager. That manager is responsible for the performance of all the team members. Since the performance of the individuals of the team are directly tied to the body of work the team commits to and the execution of that work, he/she is responsible for the team's execution.

What are your thoughts...let me know who you think is responsible for the team's execution...

Agile Product Management

2009-10-18T22:37:00.002-04:00

So I've attended both ProductCamps here in RTP, NC. During our most recent one, I presented "Agile Product Management". The presentation can be found here which is on my website : www.peterghali.org.

A couple of key points:

Scrum\Agile really misunderstand the role of product management and try to box it in to this "Product Owner" role. Unfortunately, you can't fit a square peg in a round hole...there are some struggles.
Product Manager who are also SCRUM "product owners" will struggle trying to embed themselves in SCRUM while also being the market expert that executives expect them to be.
When giving the presentation I tried to focus on introducing the problem and then presenting techniques and open discussion on how folks can solve the problem.

The presentation also covers several techniques for feature prioritization that were presented at the most recent Agile 2009 conference (with proper credit given).

The following quotation from Bob Galen's Scrum Product Ownership book says it all : "No wonder we have tension in the agile community where we have Product Owners who are struggling to balance their roles against organizational Product Management expectations"

Let me know what you think!

Changing your Sprint Length

2009-10-11T15:05:00.002-04:00

So we recently undertook an "experiment" to switch our sprint length from 2 weeks to 1 week. This was due to a high priority project that needed some extra visibility and ability to "course correct" if something came up.

Here are some things to keep your eye on if you decide to reduce your sprint length:

Meeting Overhead - You are now doing your sprint planning, review, and retrospective more often. While some may say that these meetings need should be reduced in length, the reality on the ground is that the shift in sprint length causes enough of a change where the meetings will likely take the same amount of time.
Product Owner Time frames - With a two week sprint you get 2 backlog grooming sessions before the next sprint starts. That allows you more than enough time to get the backlog estimated and in order to ensure a smooth sprint planning. With only 1 backlog grooming session, the churn is constant and its harder to stay ahead of the team. Remember if the team decides to quickly move in another direction, you also have to keep your management aware of the changes.
Work Size - The team is quite used to 2 week sprints. There is a comfort level with the size and estimate of the work. With 1 week sprints you can easily find it difficult to know the right amount of work to take on.
External Tasks - A 1 day vacation or an illness of a team member because material. All day meetings or long 2-4 hour meetings become material and difficult to manage. Don't forget to plan accordingly.

Be mindful and aware...if you know these "gotchas" ahead of time you can prepare and mitigate accordingly.

When the Product Owner has to say no

2009-10-04T15:23:00.002-04:00

I read the following blog post "When the Product Owner has to say no". Intriguing but I could resist the urge to comment.

The scenarios where Product Owner has to say no in the blog post were quite true. To me, the Product Owner has to be able to say no and sometimes make those difficult trade-offs between which customer or internal stakeholder gets what they are asking for and which ones have to wait. Until you've had to sit in front of a VP and explain those trade-offs and why that VP didn't get what they needed, you haven't earned your chops as a Product Owner.

Here's what I take issue with the conclusion: "Many NOs accumulated in the course of a project are a symptom of a failure in the PO performance." While I have no problem taking responsibility for my actions and learning from them. I do think this type of broad generalization leaves out of a lot of key facts:

Sometimes the Product Owner has to say no to an internal stakeholder in order to keep the team focused on its goals and commitments. This is not due to a failure in PO performance, but rather a lack of focus from other folks
The Product Owner is part of the team. While some may say that they are the single "wringable" neck, I'd like to think that the team can self-manage to prevent these types of unwarranted behaviors.
Part of the role of the Scrum master is make sure that the team is acting agile and following scrum practices. Many of the issues noted by the author of the blog post indicate a lack of leadership on the part of the scrum master.

I'm all about taking responsibility, but I'm not about the "blame the product owner" for everything mentality.

A Follow-up from Last week

2009-08-16T15:39:00.003-04:00

So last week I shared with you that I read Strengths Finder, but I didn't share my specific strengths. So here they are:

Restorative - Chances are good that you are mentally quick and highly resourceful. You constantly consider how you can upgrade all sorts of things in your personal or professional life. You eagerly seek and find opportunities to better yourself.
Achiever - It’s very likely that you work industriously to finish all your daily assignments. You derive a great deal of satisfaction from reaching goals others have set for you. Meeting their expectations for the day undoubtedly is one of your top priorities.
Harmony - Because of your strengths, you long to attain mental and emotional steadiness in your personal and professional life. For this reason, you prefer to perform all the tasks assigned to you each day.
Learner - By nature, you frequently examine the factors leading up to an event. Therein you discover the reasons why things happened the way they did. A number of individuals and/or groups probably appreciate your logical thinking style.
Context - By nature, you are quite intrigued by history’s significant events and people. Instinctively, you may examine certain kinds of circumstances, opportunities, or problems.

The best thing I read this weekend

2009-08-09T13:34:00.003-04:00

So, I read "Strengths Based Leadership" and took their assessment this weekend. It was a pleasant read and has tidbits of information that were insightful. It found was that there are no series of traits or strengths that all leaders typically possess. Rather, is it identifying your strengths and building a team around you that will complement (not compliment) them. It goes through 4 case studies of corporate leaders and how their differing strengths were utilized to lead them and their companies to success. While this was a bit intriguing, it was NOT the best thing I read this weekend.

The best thing I read this weekend was a 1 page article in BusinessWeek. It is titled "The Best Leadership is Good Management (click here). Can you lead and manage at the same time? This reminded me of MBWA (Management By Walking Around). It is a great technique for talking to folks, developing trust, mentoring and guiding, and of course, managing!

On the Origins of Agile

2009-08-02T09:13:00.010-04:00

So, as a practicing Agile Product Owner, with a more traditional product management background I decided to dig a bit deeper into original "founding fathers" of agile to understand their backgrounds. I've done some digging around and you can see the details below. All of the "founding fathers" of agile had a generally homogenous background founded in technical disciplines such as engineering, computer science, and physics. We all know that when you have homegenous teams, the results you tend to get are not as strong as those teams that are more diverse. I'm curious to know if agile manifesto and agile principles/techniques could be improved by revisiting them from a more cross functional perspective. We all know it takes more that developers to deliver software!

What are your thoughts?

Here is some of the research I did to review their backgrounds. While I realize I cannot encompass the full breadth of their experiences, you get the idea...

Mike Beedle - Technical Background - PhD in Physics and he has published in several areas including object technology, patterns, components, frameworks, software development, programming languages, reusability, workflow, BPR, and Physics.
Arie van Bennekum - Technical Background - Started his career as a developer and he has a IT education.
Alistair Cockburn - Technical Background - B.S. and M.S. in Computer Science with a PhD. He has been a hardware designer and research staff member.
Ward Cunningham - Technical Background - He has also served as Director of R&D at Wyatt Software and as Principle Engineer in the Tektronix Computer Research Laboratory before that.
Martin Fowler - Technical Background - He started working with software in the early 80's and in the mid 80's I started getting interested in the then new world of object-oriented development. I started to specialize in bringing objects to business information systems, first with a couple of companies and then as an independent consultant. In the early days this was using Smalltalk and C++, now it's Java, C# and Ruby.
Jim Highsmith - Technical Background - He has held technical and management positions with software, computer hardware, banking and energy companies. He has a B.S. in Electrical Engineering and an M.S. in Management
Andrew Hunt - Technical Background - Andy has been writing software professionally since the early 80's across diverse industries such as telecommunications, banking, financial services, utilities, medical imaging, graphic arts, and Internet services.
Ron Jeffries - Technical Background - Ron has been a systems developer for more years than most of you have been alive, and his teams have built operating systems, compilers, relational database systems, and a wide range of applications.
Jon Kern - Technical Background - Degree in engineering. Held positions such as Director of QA, Software Architect, etc.
Brian Marick - Technical Background - B.S. Math and M.S. in Computer Science. Lots of experience as a programmer and tester.
There are more, but you get the idea...

Test Driven Development is not the same as agile!

2009-07-16T10:09:00.005-04:00

So I was reading a recent blog post on this issue here. Here are a couple of key lines that really struck a chord with me:

Over the last several years managers, directors, and executives have asked me to present empirical evidence that Agile will cost them less money and take less time

This is a great question. I'm interested in data from the community?

A recent paper (here) published by Microsoft and IBM, showed that practicing TDD versus general unit testing reduced bug density by 40-90%. Reading this paper gave me one data point; bugs are one of the three things listed above that customers hate the most. The question is can bugs be equated to time and money?

This is really insightful and would suggest a renewed focus on eliminating bugs to reduce cost. But the author fails to include which is listed in the white paper is the associated cost of TDD. Here are the costs as noted by the paper "Subjectively, the teams experienced a 15–35% increase in initial development time after adopting TDD." Despite the increase in additional development time, TDD is worth it as the costs of fixing issues post-customer launch is very high.

Overall the author of the blog has the right idea, that TDD is the way to go! However, he seems to conflate agile and Test Driven Development. They are two distinct things. One can practice agile and not TDD and vice versa. Now we can debate whether or not you should write unit tests for "private" methods :)

Benefits of Agile Software Development

2009-07-06T20:25:00.005-04:00

Agile Software development is well documented all over the place. You can see the agile manifesto here. I'm not going to expound on all the details that already all over the place, rather I'm going to focus on the benefits that I have seen in practice. Enough of this theory and explanation of how agile would ideally work, here's the real scoop. There are some drawbacks of Agile and other benefits, more on that later.

Customer's change their minds and that is ok - The burden on trying to know every single detail of the customer/market requirements is greatly reduced. I have never worked in an organization where there were enough product managers to do everything that product managers are supposed to do. Having to write complicated and detailed technical requirements up front before development begins was always a huge burden. I hate being on the critical path. With Agile, I don't have to know every detail up front, I can accept the fact that the customer can see the product and change their mind.
Estimating work is much better in Agile - I love the concept of story points and velocity. It let's the team achieve a natural capacity and work speed rather than trying to work overtime to achieve an unrealistic deadline because the product manager took too long writing the requirements.
Team work is really emphasized - This is the real strength of Agile. Teams work together, teams communicate daily, teams communicate verbally. It just works well rather than just trying to throw "artifacts" over the fence to the development team.

The best advice I ever got

2009-07-05T14:24:00.003-04:00

I read this recent article in Fortune (here) and wanted to share with folks. It contains interviews with several well known business leaders in which they share the best advice they ever received. I typically enjoy these types of articles as they allow us to "peak" into these personas to see what makes them tick. While I'm not in the same league as those folks, I did want to share some advice I've received that I'll never forget.

I used to work for a fellow by the name of Alex Bloom (now CEO of Handango) and he told me one time that "Results matter". I know this seem quite obvious, but often times folks jump into a situation without thinking of they can truly deliver results. It has to be tangible and deliver business value. So think about this before you accept your next project. No one jumps into a pool before checking to see if there is any water.

Another piece of advice I'd like to share with folks is "Always be prepared". Everytime I walk into a meeting I want to know my audience and be the most knowledgable person in the room. Everytime I ask a question, I want to have a good handle on the answer before I ask it. Everytime I prepare a presentation I want to know my audience and anticipate their questions. I always get a warm fuzzy feeling when a person in the audience asks a question during a presentation and I respond with "Great Question, I've answered it on the next slide".

Theory vs. Reality

2009-07-04T23:41:00.004-04:00

When I got my MBA and they taught me about organizational culture, motivation, compensation, etc., I formed this ideal image of HR as playing a critical role in fostering an intangible resource (people) through all of the many things that HR can do. I thought to myself...this is how it should be!

But one step into reality has taught me that theory and practice are not quite one and the same. In reality, I've worked at companies where HR focused strictly on dealing with compensation and was nothing more than a blunt tool to be used when costs needed to be cut. I've also worked at one place where HR reported into the CFO. I thought to myself what message does that send to folks?

So I got to thinking, why is there such a disparity between what is taught in the classroom and the reality that I see. Then the answer hit me! The professors that teach these courses are rarely industry HR veterans, rather they are PhDs who get "real world" experience when they get hired as consultants to fix companies problems. So essentially I'm getting a consultant's perspective. How many of us have ever had a great experience with a consultant?

A Thought regarding a recent CrankyPM post

2009-06-20T22:47:00.002-04:00

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:

Where is the home?
Is the home big enough for my family?
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

2009-06-10T15:17:00.005-04:00

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

2009-06-05T23:16:00.006-04:00

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?

Using Social Media

2009-05-16T14:06:00.002-04:00

Good Discussion on Social Media and Business to Business interactions.

Social Media is Interaction, Engagement, Conversation, Relationships, not about Tools!
Recommenders and Purchasers are consumers with expectations
Social media allows an instantaneous response to serious brand issues. You have to live with the bad parts of social media, but you can choose to live with the good.
Private twitter accounts? I didn't know that existed! Yammer is similar.

ProductCamp RTP - 1110

2009-05-16T10:55:00.003-04:00

Product Management - 10 important things we must do:

Think - Take time away or you can easily become swallowed into the tactical.
Leadership - 90% of your job.
Pricing - Product Management should own the pricing of their product. Pricing is the only thing that brings in revenue
Measure - Customer Satisfaction, Defects, Costs, etc. Track and share. It's easier to lead when you have the information to lead.
Observe - Watch and learn. Observe your customers, determine why, and learn.
Define your personas- Who are your buyers vs. users. Know their background, daily activities, etc.
Call Reports - Validate assumptions, Discuss new opportunities
Manage Roadmaps - Feature vs. Release based, Most important deliverable, review weekly. Make your roadmap, fill it in with key milestones and strategy.
Win/Loss Analysis - Helps identify key features. Sales Process problems. Win\Loss analysis will be a career differentiator.
Write Problem Statements - Don't just have it in your head.

ProductCamp RTP - 1015

2009-05-16T09:09:00.003-04:00

So far I'm liking my first session regarding making sure that product managers understand needs. What are the needs of segmentation models and the individual user, but don't forget the other user personas. Lots of great discussion on innovation vs. market share vs. financial targets, etc.

ProductCamp RTP - 0900

2009-05-16T09:03:00.003-04:00

Well I can't believe it, I'm here on time and I'm blogging away. The team of folks organizing the event could not have done a better job. Here's a photo:

ProductCamp RTP

2009-05-15T23:38:00.002-04:00

Tomorrow is the big day! I'm looking forward to attending and will be blogging throughout the day. For more information please check it out here! Follow us on twitter as well here.

The Root Cause

2009-05-12T13:07:00.003-04:00

Have you ever been in a meeting where developers were talking about what frustrates them? That's a tough meeting to go to. You often hear similar types of complaints:

The requirements changed at the last minute?
A developer would like to make sure the work he is doing is the right work?

What is the source of all of these "bad smells"? I typically try to dig down to the root of the problem by always asking "Why?" 3 times. So let's give it a shot:

Why did the requirements change at the last minute? - Some executive swooped in to give their two cents?
Why did the executive swoop in? Because they thought they knew better
Why did they think they know better? Because they don't trust the folks they hired to do the right job

Next time you think something smells a bit funny, just ask why 3 times :)

Product Marketing 101

2009-05-03T20:45:00.002-04:00

Often times I've seen product marketing material and positioning focus on features of the product. This is the easy first step for technical product managers or engineers to jump right into. You ask an engineer "Why should the customer buy this product?" and the answer you get is "It does A, B, and C"...Let me propose another way

Focus on the customer's problems and needs. Make the marketing about solving their needs, making their pain points disappear. Also keep in mind the audience. Is your buyer or the person you are trying to reach with this content very technical? Do they want to hear detailed specifications or how you are going to make their lives easier?

Here is a good article that I like. Click here.

My "100 day" plan

2009-04-26T20:51:00.000-04:00

So I'm starting my new job tomorrow and have been hearing a lot lately about Barack Obama's first 100 days and how he has fared. So I thought to myself, I should consider where I want to be after 100 days on the job and what key milestones do I want to have accomplished. So here we go:

I want to be considered as SME regarding my aspects of the product
I want to be considered as quite knowledgeable about the entire product set
I want to reduce the workload on my manager
I want to feel comfortable with the product development process
I want to start to build trust with my team

I know that there aren't really specific or measurable, but they are areas where I will be tracking my progress.

Some interesting reading

2009-04-24T12:11:00.002-04:00

So the other day I sat down with my friends "Businessweek" and "Fortune" and got two interesting tidbits of information that really resonated with me, so I thought I'd share:

From Carol Bartz, CEO of Yahoo! - "Yahoo was amateur hour in the past when it comes to product management..groups haphazardly released things without a clear sense of whether customers wanted them. From now on she has promised, products will arrive on schedule so that customers can offer feedback".
From Massimo d'Amore, Pepsi Americas CEO - "Aiming for perfection is the enemy of good progress". This one really struck me...A lot of times I've seen grandiose visions and beautiful powerpoint presentations, but the reality on the ground was that there was no real progress being made. While striving for perfection is important, I'd rather focus on good progress!

Leaving a job

2009-04-20T21:55:00.003-04:00

So as many of you have noticed, its been a while since a couple of weeks since I have posted anything. Who am I kidding..."many of you", I doubt that anyone besides me reads this blog...but anyways...The reason why it has been a couple of weeks is that right now I'm between jobs. Leaving a job can be a trying and difficult time, but it says a lot about your character. I've seen employees pretty much say "screw you" and leave. I've seen folks give their two weeks notice, but somehow disappear. I've gone through my fair share of job transitions and here are some lessons I have learned:

Be there - Support your team as you transition. They will likely need what is in your head and supporting them will likely leave them with a positive memory of your work. I remember the following quotation quite vividly "A man is not defined by what happens to him, but rather by how he reacts to what happens to him."
Be positive - No matter how frustrated or angry you are, focus on the lessons learned and how you can apply those lessons in the future.
Give yourself some time off - If your financial situation allows for it, a couple of days, weeks, etc. can allow you to get back to those things you neglected while you were working those long hours. You'll start your new job feeling refreshed and energized.
Ask for feedback - Now that folks know you are not sticking around, it may be a good time to ask for candid feedback. This is a good opportunity to learn about how others view you so you can avoid making the same mistakes at your new job.

2009-04-07T16:00:00.002-04:00

Every once in a while I like to take a moment and reflect on some key lessons that I have learned. Given that I am transitioning to a new opportunity I thought that this would be a good time to share some thoughts...

Listen
This is an important skill that I see so many managers and leaders lacking. After managing my team for several months I learned that you have to listen to, learn from, and respect everyone you work with. When folks know that you are listening they listen to you as well. Projects and people move forward when they listen.

Manage Knowledge and Information
In a technology company you have to know your product. This can be complex. Set up a wiki, document your knowledge to share with others. This will not only help you learn and grow, but also help your team and others. This can drive sales enablement materials as well.

Know your audience
When you give a presentation think about your audience and the perspectives they have and questions they may have. I'm also a big believer in managing your manager. As an employee it is important to understand your manager's style of communication, likes and dislikes, etc. Leadership is about the ability to influence and you can't influence that which you do not know.

Be Positive
Sometimes its easy to get bogged down in the negative. Focus on the positive. For me, I've focused on what I have learned and how I have grown as a product manager. I am also quite thankful for the opportunities i have been given. Nobody likes to work with a grumpy product manager!

Your success is defined by the success of your team
As a leader and manager of a team, it has always helped me to be a "servant leader" to enable my team's success. I have taken a lot of pride in developing and growing the team to help deliver the best product and product information to market. Allow your team to succeed and your success will follow

Succession Planning is important
I know we typically hear about this for CEOs and other C-level executives...but succession planning for your team? I say yes! If you have done a good job mentoring your team and leading them to success, then this won't be that difficult. I recently transitioned into a new role within my former company and my previous team didn't miss a beat. It feels a bit weird to not feel needed anymore, but I can honestly say I'm proud of that accomplishment.

Transparency in product development
When I started my role running the program and project teams, things were a mess, nobody knew where the projects were in the "process" and nobody knew who was working on what. The first thing I did was put "windows on the factory". We started tracking how our resources were being allocated against our priorities and we defined a simple process that was just enough process for us. We could now track our projects against this process. It wasn't perfection on day one, but it was clearly a step in the right direction.

Some Recent Research

2009-04-03T13:29:00.003-04:00

As a North Carolina State University graduate, I still do follow the business school and latest news. Yesterday this came across my inbox:

Studies Show That Nice Guys Finish First in Business World
When it comes to leading a team tasked with developing new products and bringing them to market, new research by faculty at the North Carolina State University College of Management shows that being nice and playing well with others gives you a very real competitive advantage. Read more

So, let me get this straight..a tenured professor at NCSU just figured this out? A junior project manager can tell you that!

Meetings and Laptops

2009-04-02T13:31:00.002-04:00

I know that this is a lot of debate about allowing laptops in meetings. Nothing is more annoying tha when someone is typing away and then something comes up and they are asked a question. The deer in the headlights look and then having the repeat the past 2 minutes of conversation are quite wasteful.

When I run a meeting I don't have a particular rule to have all laptops closed. I do, however, prefer to keep my laptop closed when I attend meetings. I find the use of a pad of paper and a pen to take notes and then going back to my desk with my notes is nice...sometimes its nice to not to get away from your laptop.

What do you do?

2009-03-27T15:23:00.000-04:00

A lot of times, folks ask me what I do for a living...whenever I say product management, the first thing I hear back is either "What is that?" or "So do you like being a project manager?"

Product management is sort of difficult to define to those outside of the corporate world. I always explain it to folks by saying that a product managers job is to understand the market and work with the team to define a strategy and plan to ensure product success. Sometimes you find that product management reports into marketing, into a technology, or as a stand alone business group.

I also find myself explaining the differences between program, project, and product management to folks. I know I've oversimplified it, but here's my quick and dirty explanation:

Project - Works to determine when the feature will be released.
Product - Works to determine what features are important and what the feature is. In some companies the product manger has P&L responsibility.
Program - Across project resource allocation and project coordination. This function can manage one or more project managers for a particular account or product.

Anyways, that enough for today on that little pet peeve :)

Black and White

2009-03-23T00:49:00.000-04:00

Earlier in my career I was sort of a black and white type of guy...as I now know, the world is filled with a lot of shades of gray. You'll often have conflict between scope and deadlines or between quality and deadlines, etc where the answer isn't always black and white. As a project manager and product manager I've learned that understanding, quantifying, and minimizing risk through communication with the team is essential. There are two things that have helped me in guiding successful teams and I thought I'd share with you:

Listening - This cannot be overstated. Even if you disagree with the perspective or opinion, acknowledgment of that opinion goes a long way to building a team consensus. When you listen you might actually learn something.
Be prepared - I have a rule that I work to be prepared for meetings. Being prepared allows you to actually know what you are talking about and you can't lead a team if the team doesn't believe you know what you are saying. Take the extra time to prepare for meetings, review the agenda, talk to the key players. Knowledge is very helpful in decision making :)

Pricing - The difficulties

2009-03-09T21:54:00.000-04:00

If you have ever worked at a small company interested in becoming more profitable, you've surely faced the difficulties of pricing your product. Many product manager typically fall into the trap of pricing by taking the product's cost to deploy (including a corporate overhead) and adding a markup. There are several reasons why this type of pricing is typically the easiest to rely on:

It's the easiest to determine since costs can easily be determined.
It requires the least amount of effort. See Reason #1
It's supposed to lead to profitability

While this may work, it is clearly not the most ideal way to price your product. There are also a lot of factors in pricing such as goals (market share vs. profitability) and also your product's strength in the market.

The Roadmap Responsibility

2009-03-03T21:53:00.000-05:00

At one point in my career I worked at a start up technology company who was really interested in getting that next sale, that next logo that they can put in their sales pitches and investor presentations. So of course the product managers scurry revising and creating their roadmaps and putting dates and milestones, etc. It's easy to put together a roadmap, as product managers we know the market, the customers, and the competition. What's hard is to put together a credible roadmap.

We have all seen roadmaps that we look back on a year later and just wonder "What happened to all of those plans and ideas?" It was likely because we didn't get real buy in and commitment. When that happens the road map just becomes a slide that some product manager created. There is no sense of true partnership or responsibility on the part of the team for delivery.

So here are a couple of tips that I have found helpful:

If you don't have buy in from the whole team, don't put dates or even quarters in your roadmap. When the sales team shows this roadmap they are going to get asked "When will you release feature ABC?". The answer is simple, this is a plan and we are working planning the release of that feature and we will let you know as soon as we have feature ABC committed for delivery. Be honest and truthful with clients, it will pay off.
Create the intial draft of the roadmap with everyone's input. It's easy for a product manager to go off and do all of this research and present a road map to the team. A better way to do that is to go to engineering and ask them for what improvements do they want to see. Perhaps there are infrastructure improvements that can make the support teams work a lot easier. Maybe some internal tools to debug issues to lower the cost of customer service. There are a lot of ideas, include everyone!
Make sure you have a product development process that provides clarity and transparency into how resources are being allocated and how the roadmap will get implemented. As a product manager you will get graded on what gets implemented, not what you define or want.

Just some initial thoughts on such a difficult subject. Obviously there is more to it than just this blog post, but these are helpful lessons I've learned.

Crossing the Chasm

2009-02-27T08:40:00.000-05:00

Recently this book was being discussed and I decided it was time for me to understand this "chasm" a bit more. I picked up the book from Amazon (I love Amazon!) and read through it and took notes. Finished it up in about a week. I would definitely recommend this book to technology product managers and marketing professionals. It focuses on the product marketing and positioning for determining a target market and what it takes to get your products across the "chasm" of early adopters into the early majority. Here's a good summary.

You can learn more about this great book on Wikipedia - Crossing the Chasm

Building trust with your team

2009-02-26T14:24:00.000-05:00

Even though I come from an engineering background with almost 10 years of experience in all sorts of large and small companies, it was a lot harder than I thought to transition into a product management role. As an engineer, I always thought that "business team" didn't really do anything and that engineering was where the tire hits the road! Now that years have passed and I'm on the other side of that artificially created opposition, I've gained a deeper appreciation for how teams can work together to build great products.

One of my first lessons as a product manager involved forming a relationship with engineering built on trust that was mutually beneficial. Easier said than done! Here are some of the lessons I learned early on to help:

Give Credit - It is NEVER about you. It's about the team! Take every chance you get to put the spotlight on them.
Be Reasonable - As a product manager you have to balance between the sales and marketing teams who say "If you don't ask for it, you'll never get it" and the engineers who say "That's impossible to develop". Challenge and learn, maybe there is a phased approached and not every feature is a P1 feature.
Establish yourself as a credible market represenative - Do your homework! Opinion's are not good enough, market and competitive data are needed to be prepared. Have you talked to customers? Prepare thoughtful questions and research.

Of course there are many more lessons I've learned, but that's enough for today....

The "Success Singularity"

2009-02-24T09:50:00.001-05:00

Sometimes we are so focused on what has to get done next and what am I doing to get this project or product done, that we lose our "finish line" focus. As a product manager who also done some heavy lifting as a project manager, I have had to learn to step back and think about what the finish line looks like and how will the team know when we have crossed it. I called today's musing the success singularity, meaning the point at which everyone can agree that the project or task has been completed. It must be indivisible. This about a track race, how do you know it's done. Simple, when the finish line tape is broken. It is the perfect definition of a "Success Singularity". It defines completion of the race and it is indivisible. By providing your teams with "Success Singularity" criteria you provide clarity and direction while minimizing potential confusion over the completion of a task or project.

My First Post

2009-02-22T21:48:00.000-05:00

Why am I creating this blog? Well that's a great question. As I have grown in my career, I wanted to have a broader dialogue with other professionals about some of my product management musings. I wanted to share some of my lessons learned and hopefully learn from you about your lessons.