product management

...now browsing by tag

 
 

How to Kill Your Product Management Career

Monday, December 6th, 2010

Big company product managers have a way of becoming inward focused and abstract.  By abstract I mean focusing on technology and business problems that have a very low probability of materializing and even if they do it won’t matter much.  Startups on the other hand, quickly put product managers back in touch with reality – as they force you to focus on the basics: selling, building products, and building awareness (aka marketing).  Here are a few signs that you are a product manager at a big company out of touch with reality and on path towards killing your career:

Your office is home: Get out of the office and  talk to customers, partners, and peers at other companies.  Sitting in your cube and having lunch with the same people every single day is the single worst thing you can do for your career.  This doesn’t mean you need to be at every conference (the polar extreme is equally unhealthy).  It does mean that the world will not come to you, you need to go it.  I have seen too many incredibly talented people innovative muscles atrophy by making their office their home.

Your side project is on hold:   Your current project is likely not that innovative.  It could be very important – like improving the scalability and reliability of Gmail (please solve this) or shipping the next version of Outlook on schedule.  What is innovative is that side project you work on a few hours a week that with a bit of nurturing could provide the seeds for something truly innovative down the road.  One of my weekend side projects provided the inspiration for my current startup.

People confuse you with a project manager:  My objective is not to diminish the role of a project manager — they can be invaluable for certain projects. But project managers don’t determine when to cancel products, don’t design and work with engineers to prototype a new idea, and don’t prioritize features amongst other things.

You attend organized (internal) meetings 80% of the day: You can’t recruit in internal meetings, you can’t design in meetings, you can’t talk to customer/partners in internal meetings.  The folks who spend all day updating executives become overhead. These are folks who aren’t the experts in anything and they aren’t driving anything.  They are well paid meeting attenders who usually say the same things over and over in every meeting.  They say it so much they get really good at saying it so some people believe they must know what they are talking about.  Instead figure out what you need to do to be the “CEO” of something — by CEO I mean earn the right to become the default person people ping for that thing — whether it be a feature-set, a customer initiative, or an entire project.

I will finish with a short story related to this point. A few years back I inherited a product management team.  One of the product managers was constantly asking me about attending internal meeting  I quickly realized he hadn’t shipped a thing because he was meeting busy — so I told him to stop attending meetings.  Judging from his facial expression I got the sense that he felt like I was punishing him – for most of his career he confused meetings with work. As soon has he cut the number of meeting he attended he started shipping more product.   He ended up switching groups a year later and low and behold he was back on the meeting circuit.  Bad habits are hard to kill.

Four Ways to Clean Up Software Feature Bloat

Thursday, July 8th, 2010

software feature bloatNo matter how bad a product feature may be removing it is 3x harder than putting it in in the first place.  Here are four ways to remove unwanted product features.

  1. Bury It First: Reduces usage to the point where it will make it less painful to eliminate.  Netflix tried removing a feature and customers complained so loudly they brought it back and buried it — see here for full details
  2. Throttle It:  Limit the capabilities of the product.  Many years ago HotJobs had a job listing product that recruiters abused by refreshing the job daily to make it appear like the job was in fact new today boosting the relevancy of the job listing. Rather than completely eliminate this product we initially throttled the number of times the recruiter could perform the refresh action and made it transparent to the jobseeker that the job listing had only been refreshed.
  3. Take It On the Chin:  If a small percentage of users are holding you back from innovating on behalf of a much larger percentage of users, kill the feature, communicate it and move forward.  Some innovative sites like Digg fell prey to a very vocal set of users who demanded the product not evolve.
  4. Replace It With Something Else:  When Facebook App Notifications were eliminated, they provided other ways for App developers to connect with users.  Nowhere near the same level of distribution but some alternatives…I hear the moans from Facebook App Developers.

Adapted from my answer on Quora.  Follow me on Quora here.

But..But..I Built What The Customer Said They Wanted

Tuesday, June 1st, 2010

At most enterprise software companies sales and its largest customers dictate product requirements.   Product managers and engineers usually just execute against these “requirements.”  These enterprise systems are rarely successful because the people setting the requirements – sales and its largest customers – are mostly confused (or don’t care) about what the users of these systems actually need to get their job done effectively.

eBay is one of the very best Internet stories.  They built a global marketplace that created economic opportunity and work-life balance for millions of people.  Very few Internet services come close to that kind of economic impact.  Ultimately though eBay got “enterprised.”  While I never worked at eBay I know many who have and they basically tell the same story Ben Foster a former product management leader at eBay explains well here:

The fear of ruining Ebay’s “secret sauce”.  Products could be vetoed by the heads of various functional units if it threatened “the community”.  But no one really knew what made the business so successful, and so there was major resistance to non-organic change.  Our most vocal and successful community members were the very same people who benefited from the inefficiency of the Ebay platform.  So we had major disincentives to innovate.
Seller focus.  Sellers paid Ebay the money, so the company focused innovation on them.  We listened to sellers that said that they wanted feature X, Y, or Z.  But we missed what sellers really wanted.  What sellers really want is for buyers to think of Ebay FIRST when they want to buy something.

This reminds me of one of the best quotes on product innovation: “Your customers won’t tell you everything, so you need to invent on their behalf” – Jeff Bezos CEO and Founder of Amazon.com.  If you are a product manager and sales comes rushing to you with a list of requirements don’t cut and paste those into a product requirements document.   Big mistake.  Listen to customers and listen to sales, but then go and do the hard work of innovating on their behalf.

Five Clues for Sniffing out Software Projects Bound for Failure

Thursday, May 13th, 2010

Spending eighteen months on a software project doomed to fail (either gets shut down or market irrelevance) is a waste of the important asset – your time. If you find yourself stuck on one of these you will pick up bad software development habits and find the innovation sucked out of you. Here are five clues to help you sniff out software project that should be avoided.

1.) Projects with Lots of Mass

My general rule of thumb is to avoid any project with significant amounts of mass in its early stages. By mass I mean lots of user research, lots of PowerPoint slides flying around, lots of executive attention, lots of developers. This chaos will generate even more chaos and usually failure. Some of the most successful projects at Yahoo! began as very small side projects: Yahoo! Answers and Yahoo! Sketch-a-Search. Find small projects with people (two three developers, a product manager, and designer) you respect with a track record of building good stuff.

2.) The Project with Three Names

If a project is not going well there is a trick to help it regain stature – rename it. It used to be called “Phoenix” now its “Marin” – problem solved! Before joining a project be sure to ask about the naming lineage.

3.) The Replacement Project

These are easy to detect. Somebody decides to follow a technical trend and in the name of flexibility, scalability, blah-blahbility decides to replace outdated an outdated technology platform with a new shiny platform (i.e the latest technology trend).

4.) The Project that Declares War

These are not hard to detect but hard to ignore, as their pitch inspires high emotional excitment. Declaring war on your archenemy naturally excites us humans. We like conflict. These projects are prone to failure because there is usually no clear angle of attack (see my post here). Rather, its lets build or sell a slightly better or cheaper version of the competitive offering. For example, if you are Monster.com trying to fend off Craigslist offering job listings for $50 is not going to do much other then erode your margins. The reason Monster is failing is because of poor applicant quality. Address that issue rather than chasing Craigslist.

5.) The Sacrificial Lamb Project

Projects that SVPs keep in their portfolio just in case somebody decides its time to start whacking some projects in the name of cost cutting. Because these are relatively rare they are also hard to detect.

If You Are a Product Manager Without an Angle of Attack, Prepare for a Blood Bath

Thursday, April 22nd, 2010

If you are a product manager and not managing a product that is a monopoly (i.e. Microsoft Office, Windows, Google Search) or strong number one then you need to figure out  your angle of attack.

This could be attacking on a set of different features, attacking from a different channel to flank your competitor, or attacking from the position of an emerging platform.  What is a viable angle of attack, lets look at a few:

A Platform 
Attack

In the gaming space users are moving from consoles to social networks.  Zynga realized that and attacked starting with Facebook taking advantage of massive user base combined with a relatively immature platform that they cleverly exploited.

The Channel
 Attack

In Japan where Yahoo has 56% search market share Google is attempting to flank Yahoo! via mobile search channel — by dominating the mobile search side they believe that overtime they will convert users on the PC.

 Over the next few months expect many companies to disrupt established players via the mobile channel.

The Missing Feature

Incumbents get fat and lazy and start overlooking important features. Skype attacked the 1:1 communication space from the angle of audio/video communication – free calls anywhere in the world. MSN Messenger and Y! Messenger should have seen this opportunity, they ultimately matched Skype feature for feature but it was too late. Skype had become a verb for talking and video-conferencing. [Skype also fits under the category of platform attack – they were one of the first legal services to leverage the broadband platform – Om has more on this here.]

Business Model Attack

Netflix is a classic example. Blockbuster business model was largely based on capturing late-fees. Netflix said we will not only deliver your movies directly to your home but you never have to pay late fees. Netflix destroyed Blockbuster.

These do not qualify as a viable angle of attack:

We’ll Out Design Them

The argument I hear fairly often goes something like this “Just like Apple we will provide a far superior user experience and destroy them because their UI sucks.” I love great design (I led the acquisition of Inquisitor for Yahoo!) but unless your design advantage runs deep (Apple’s does) a competent incumbent will steal your design and pawn it off as their own. Great design is part of an attack, not the attack.

If you are a product manager and you cannot articulate your angle of attack you are going to end up attacking head-on which is costly and bloody.

Scrapping Features is Hard (Very)

Thursday, December 3rd, 2009

Today at Yahoo! I had the pleasure of hearing Marty Cagan talk about building awesome products and a good question came up.  What companies do a good job at scrapping (aka retiring) features?  Building features is relatively cheap and easy.  Scrapping them after afterwards is very hard.  Netflix attempted to retire their Profiles features (allowing users to create profiles and set controls around on how many movies and the types of movies each profile can rent).  This did not go over well with their community.  Two weeks later they came back and decided to keep it.  Now the feature is buried deep into the Account Settings page.  This is the right way to do it if you absolutely cannot retire the feature. Here is how the sequence of events played out on the Netflix blog and site:

[Update March 18, 2010:  Another example of how hard it is to remove features from NetFlix.  I love that they have the fortitude to remove features even if a small and vocal set of users complain.]