Category Archives: Saeed

It’s ProductCamp Season!

From only 3 events a couple of years ago — Silicon Valley, Austin, Toronto — the number of ProductCamps has grown steadily. In fact, there are 3 events in the next 8 days, and there are 9 events on 3 continents  in the next 2 months! I find that simply amazing.

Here’s a list of upcoming events:

  • ProductCamp Boston – May 22, 2010
  • ProductCamp RTP – May 22, 2010
  • ProductCamp Toronto – May 30, 2010 <== Yeah!
  • (Mini) ProductCamp Minnesota –  June 2, 2010
  • ProductCamp Berlin – June 5, 2010
  • ProductCamp London – June 19, 2010
  • ProductCamp Chicago – June 19, 2010
  • ProductCamp Melbourne – July 3, 2010

You can get more information on our Events page.

And if you’re in the Toronto area, why not come to our event on May 30th?

http://www.productcamp.org/toronto

Saeed

Advertisements

The secret to Apple’s success?

If there’s one company that is the envy of the high-tech community these days, it’s Apple.  Steve Jobs is hailed as a genius CEO and lauded for a string of hit products. Apple’s market capitalization is over $200 BILLION dollars currently, easily ranking it in the top 10 companies in the world by market cap, and just shy of Microsoft for biggest technology company.

Everyone wants to understand the secrets of Apple’s success and hopefully emulate them. The reasons given by people for Apple’s success are many. The following are a few of the arguments made:

1. Vertical integration – Apple owns most of, if not the entire, technology stack for its key products,  and thus gives it advantages over other less vertically integrated products.

NOTE: “Vertical integration” used to be called “being proprietary” and was given as the reason for Apple’s relative lack of success against Microsoft in the OS/PC battles of the 80s and 9os. But phenomenal success has a way of changing people’s minds.

2. Making markets vs.  addressing markets – Some claim that Apple doesn’t ask people what they need but gives them products they decide they want.

Does anyone NEED an iPhone or iPad? Not really, but a lot of people seem to want them.

3. The Cool Factor – Let’s face it, Apple does make “cool” products. Attention to design and detail – fit and finish as they say – really distinguishes Apple’s products from competitors.

4. Entering markets after they’ve developed — Contrary to #2 above, some people claim that Apple doesn’t make markets but enters existing markets once they’re growing and takes  advantage of latent demand.

The iPod was not the first digital music player and the iPhone was not the first smart phone, and the iPad is not the first portable computing device. In the case of the iPad, products like the Kindle and Netbooks actually paved the way for the market to accept  small computing devices, and Apple’s iPad is riding that wave.

5. Differentiated business models – whether it was iPod+iTunes or the iPhone+App Store, Apple innovates not just on technology, but on the business model. This makes it difficult for competitors to play catch up, let alone overtake Apple once it establishes itself in a dominant position.

6. People care about the experience not technology — Apple has always been about the user experience, but for a long time, the majority of the market didn’t care about that.

The majority of desktop computer users cared about “techs and specs”.  Now the tables have turned, and the majority don’t care about the specs, they care about the experience. The iPod, with it’s “1000 songs in your pocket” motto and iTunes which radically simplified purchasing music latched onto the experience wave, and Apple has been riding it ever since.

7. Simple product offerings – Apple has a very clear and simple set of products. It’s easy to understand the differences between their products, product families and the various configurations. This makes it easy to buy an Apple product if you want to.

A lot of companies complicate things unnecessarily. How many iPhone models are there? How many Blackberry models are there? How many Nokia smart phone models are there? See the difference between Apple, RIM and Nokia?

The same is true for the iMAc, the iPod and the iPad. Granted, there are actually a number of iPod models (Nano, Shuffle, Touch etc.) but they are very distinct amongst themselves. This can’t be said for digital music players from other companies.

I’m sure there are other reasons for Apple’s success, but it’s interesting to see how much debate is happening today on this topic. What it says to me is that there is no single reason for their success. And keep in mind that Apple has had failures as well.  Notice Apple doesn’t talk much about Apple TV. And remember the G4 Cube? The 20th Anniversary Mac?  Even the ultracool MacBook Air has had far from stellar success.

So, what do you think are the reasons for Apple’s incredible success over the last 10 years?

Saeed

The Importance of Perspective

Steve Johnson has a video on his site that shows a wonderful optical illusion. I’ve embedded it here for your viewing convenience.

This video is a great example of how important a role perspective plays in how we interpret our environment.

Perspective is also incredibly important for people when researching, designing or building products.

Specifically for Product Managers, it’s important to be conscious of how your perspective (your background knowledge, assumptions and existing viewpoints) on a situation influences how you interpret it.

To maximize your perspective, and avoid false assumptions and conclusions, try to get as many inputs as you can when researching requirements. This does not simply mean talk to more people, but make a conscious effort to to improve your domain knowledge, document and validate your assumptions clearly, and talk to different types of people in different roles, in different types of companies and with different needs.

It’s actually quite amazing how much insight you can gain by consciously broadening your perspectives on a given situation.

Saeed

Product Management Metrics (part 2a)

My  conference call on PM Metrics with Tom Grant went quite well yesterday. It was a round table discussion with good points made by several participants.

While we did talk about a number of topics, the metrics discussion dominated the first 1/2 of the call.

One of the questions  — What metrics should be used to measure the effectiveness of Product Managers? — got me thinking a bit.

My answer on the call was that first the focus should be on metrics for the Product Management organization, and then a breakdown from there on metrics for individuals based on objectives and tasks that support the goals of the organization.

To me that seems like a logical approach, because all other organizations in a company, includes sales, marketing, technical support etc. have metrics defined and measured that way.

So what’s the problem?

So why is it so hard to come up with metrics for the Product Management organization? Well,  it goes to the heart of the major issue with hi-tech Product Management today.

And that is that most companies don’t look at Product Management as a holistic function within the company, but rather as a set of individuals or small teams working on a variety of product related tasks.

Look around and see how the focus of Product Management is different in different companies.

Look at how widely the reporting and organizational structures are for Product Management. It is part of Marketing in some companies, part of Engineering in others, a standalone department in others.

Look at the ongoing debates related to when Product Management roles should be defined and introduced in a company.

If you’ve worked in or have been exposed to Product Management in different companies, compare and contrast the tool sets (or lack of them) used by Product Management organizations versus the tools used by other departments to do their jobs.

And if people don’t look at Product Management and it’s objectives in any holistic and standard way, how can they set about defining and measuring key metrics for the Product Management organization?

Metrics should focus on measuring intended outcomes

For Sales organizations, the key metrics  (product sales/bookings etc.) are directly tied to the intended outcome of the function: generating sales and revenue.  There are numerous secondary metrics that are tracked such as  sales breakdown by product/product family, by deal size, by geography, by new vs. existing customer etc.

And don’t forget all the sales funnel metrics that are used to track progress and success, such as average time to close, win/loss ratio etc. The important metrics are clearly tied to the intended outcomes of the activity of the sales organization.

For marketers it’s a bit more complicated because there are different roles in marketing and different intended outcomes. The two primary outcomes that can be applied to marketing are related to lead generation and market/industry awareness.

And from there numerous metrics can be identified related to number of leads, cost per lead, lead quality, lead to prospect conversion ratio etc.

Metrics for awareness are numerous, but basic metrics focus on “mentions” by press, analysts and other influencers in publications, reports, blogs, and via social media such as Facebook and Twitter.

And what of Product Management?

What is the primary objective of Product Management? In a previous article on this blog entitled Product Management Metrics (part 1), I defined the mandate of Product Management as:

To optimize the business at a product, product line or product portfolio level over the product lifecycle.

Don Vendetti of Product Arts, wrote a series of guest posts, entitled Measuring Product Management. In part 3 of his series, he provided his definition of the Product Management mandate:

To deliver measurable business results through product solutions that meet both market needs and company goals.

I like Don’s definition.  Both definitions share the same spirit about business focus,  but Don’s phrasing is clearer and more explicit than mine. But I do think that mention of the product lifecycle is needed because that has a huge impact on the objectives and the required focus of Product Management.

Don’s use of the words “measurable business results” is crucial to this discussion.

So what are those business results? Well it depends on the business and the company goals. 🙂

Those goals depend on the many things. Some companies care about revenue. Others care about market share. Others care about profitability. Others only care about getting acquired. And those goals can change with time.

Some choose to be technology focused, while others are sales, marketing or market focused. Some companies have a single product, while others have portfolios of products.

Depending on the company’s goals, size and level of maturity, the market conditions, it’s financial status and it’s overall strategy, Product Management’s objectives will change and so the metrics to measure Product Management will also change.

I’ll stop here, but I’ll pick up this discussion in an upcoming, and long overdue post that will be entitled Product Management Metrics (part 3).

Make sure you read Part 1 and Part 2. 🙂

Saeed

Product Management metrics with Tom Grant

On Wed. May 5, I will be participating in a live teleconference with Forrester Analyst Tom Grant and a number of his clients.

We’ll be discussing a number of issues related to Product Management, but focusing on metrics that are important to the field of technology product management.

I’m looking forward to the discussion and hope to learn as much as I contribute.

You can find more information about the call on Tom’s Forrester blog.

Saeed

The Bad of Product Management

Here’s part 2 of the results from my survey. Part 1 — the Good — was published last week.  Following the same format as Part 1, I’ve categorized the open ended answers into specific categories and the picked some of the most representative responses for each of those categories.

The question asked in this case was:

What are the top 3 things you *DON’T* like about your role? (The BAD)

NOTE: Please list things that you actually do in your job or are enabled to do.

NOTE: It was actually harder putting these responses into appropriate categories than it was for the Good. Sometimes responses straddled 2 or 3 categories that I had used. In the end, I did my best to be consistent about the categorizations.

And with that, here are the results:

Tactical Responsibilities

By far the most common thing disliked was having to do what can best be described as very tactical tasks. I don’t think this is unique to Product Management, but there was a really long list of these types of answers in the survey responses.

  • Writing detailed specifications
  • Bug triage
  • Product demos
  • Sales support
  • Writing collateral
  • Handling support escalations
  • Writing white papers
  • RFP responses
  • Mundane research
  • Creating data for customer demos

The general sense I had when reading these and other similar responses is that a lot of time is spent doing these things and that time could be better spent in more valuable tasks.

I’m surprised no one mentioned being responsible for the dreaded “Platform Availability Matrix”! 🙂

Lack of Authority

The next most common category was related to authority (0r more commonly the lack of it) for Product Managers. This is not news but it is not a good sign if this is still the case in many companies.

  • Little influence on R&D operationally
  • No ultimate decision making authority
  • Competing priorities when leaders/groups want to hedge their bets to avoid making final decisions
  • Realize very little of the planned funding for roadmap projects
  • Executive desire to control – effectively defeating a PMs authority/influence
  • Limited opportunity to affect business strategy
  • Micromanagement of products by upper level management
  • Too often the PM is charged with applying a thin veneer of the latest hot biz idea over current development efforts even when the idea conflicts with the product vision, core belief or functionality
  • Execs deciding strategy with no information or input

People Issues

This is a bit of a catch-all for things related to team work, interaction with other groups, organizational structure  etc.

  • Org structure that inhibits team participation by team members
  • Babysitting R&D (and/or sales)
  • Bad leadership, really bad
  • Responsiveness of the people I’m depending on
  • PM leadership directly converted from Engineering but pretend to be visionary PM
  • Having to manage under performing direct reports
  • Not having a mentor or someone to learn from
  • Mediating between conflicting departments re: product issues
  • Lack of strategic guidance from the executive team
  • Doing other people’s jobs to get the product out

The comment on mediating between conflicting departments is interesting. I don’t know how much mediating that person does or what kinds of conflicts occur, but I found that comment somewhat strange.

The fact that you’re being called to mediate shows those teams respect you enough to have you help them address these issues. At least that’s what I’ve seen in my experience. Not all PMs are called in for those situations, and if you are one, understand why.

Culture

Responses that sounded like they are part of the company culture ended up here. Culture plays a critical role in successful companies and it’s important that Sr. Management understands this and sets the right examples.

  • Ongoing dealings with unrealistic expectations internally
  • Working with teams who don’t care that much about the product
  • People more dedicated to processes and polices than actual outcomes
  • Organization tends to respect product managers who are into technical minutia, not strategic vision
  • Back and forth executive decisions
  • Working with R&D that is unable to make a design freeze
  • A slow inclination to change
  • Good ideas always take too long to reach the market
  • Everything is hurry up and wait

Politics

Where would product management be if it didn’t involve politics? Politics is not always a bad thing, but unfortunately, it’s human nature to take care of number 1 first, and then worry about what’s best for others.  Here are some of the responses:

  • Wresting with other teams to get things done
  • GMs so busy with politics and budgets that they forget about customers and users
  • Juggling the slate to accommodate politics or last minute requests
  • Politics of who owns design

Project Management

An oldie but a good. There were a number of respondents who simply wrote “Project Management” as one of their dislikes in the job.

OK everyone, repeat after me — A Project Manager is NOT a Product Manager. Again. Again. One final time. OK, problem solved?

Lack of Resources

  • Inability to allocate resources to my project
  • Not having enough resources
  • Lack of evangelism resource. To get product to market effectively, you need to help drive feature adoption

Lack of Direction/Definition

  • Lack of broader understanding of expections of Product Management
  • No being challenged enough by Management
  • Lack of definition of the role
  • I have so many different hats/roles to play

Lack of Customer Contact

This came up several times. If you are a PM and your company won’t let you talk to customers, the company doesn’t understand Product Management. You should try to help them understand, but if that fails, seriously consider changing employers. It’s not worth figuratively banging your head against a wall every day.

  • Not being able to talk to customers indirectly or directly
  • Not allowed to visit customers
  • Can only talk to customers when a sales rep is present

Other responses

There were quite a few responses that covered various themes such as workload, job pace, constraints, compensation etc.

  • Sometimes a dumping ground
  • Can be quite exhausting at times
  • A struggle to keep the respect of other departments
  • Working without enough data
  • PM is never really appreciated – [this person should read this post.]
  • All the blame, none of the glory – [and this person as well!]
  • Volume of email
  • Can’t get it all done – [prioritize! 🙂]
  • Not enough time for family and hobbies
  • Communication overload when every problem a stakeholder can’t figure out gets sent to your desk as you seem to know everyone
  • Lack of documentation for all the “gotchas” of our product. No simple way to communicate them to those who need to know
  • No documentation on the history of our products – what was added/changed in what release – [it should be in the release notes or ‘What’s new’ document 🙂 ]

The final set of results — what people want to change — will be published in the near future.

What are your thoughts on these responses? Do they mirror your environment? Any advice you want to give to the people who wrote these comments?

Saeed

Product Management in Pictures #5: If Hardware was built like Software