Monthly Archives: October 2010

We won…thanks to everyone who voted!

I guess asking, pleading and threatening all paid off. We came in first(!) in the Professional Life category of the 2010 Canadian Blog Awards.

So, thank you everyone for your support. We even beat out last year’s winner,,  which was also a finalist this year.

Last year we were a finalist, but only placed 4th out of 5. So this is a great result.

We’d like to give a special thank you of some kind to everyone who voted — well actually, everyone who voted, AND who left a comment or a tweet!

That means you @BstnMelody, @BarryPaquet, @samx18, @StewartRogers and of course Yogi.

Did I miss anyone?

So what could that special thank you be? Any suggestions?


Vote for us, or else! :-)


Voting ends at 12:00 noon EST on Tuesday Oct. 26.

Don’t miss your chance to help make a Product Management blog a top Business blog.

If you’ve already voted, great, you can VOTE once per day! Yes, those are the rules!

Click —>> here <<— and vote for us! The image below give you any additional info you need. :-)

Thanks, and please leave a comment to let us know if you voted.

Open Question: Why did you become a Product Manager?

My previous Open Question asked what you did before you became a Product Manager.

This time I’m interested in hearing WHY you became a Product Manager?

In my case, back in the late 80s and early 90s (yes, I’ve been working in high-tech for a long time) I had worked in a couple of not so successful startups. They failed for a number of reasons, but in one company, the failure was primarily due to being almost completely technology driven and lacking almost any aspect of market focus. Here are a couple of examples:

  1. The VP of Engineering once said (and I’m not making this up): “Customers don’t know what they want. I know what they want.”
  2. The CEO said (in response to a suggestion (by me) to do some market research before deciding what to build): “Who needs market research. By the time you finish the research you could have already built the product.”

There were many more Dilbert moments like these from that company.  One bright spot at that company was a rather short-lived VP of Marketing. She understood Product Management and opened my eyes to how things should be done. Unfortunately she left the company before changes could be made. I decided that Product Management was what I wanted to do next.

I wanted to work in a company where there was a customer and market focus, and where some level of discipline was present when making decisions on what to build. In short, I wanted to work in a company that had more than just a hope and prayer of being successful and I wanted to play a role in that success.

And that’s why I became a Product Manager.

What’s your story? Leave it in the comments below.


We still need your votes! Please :-)


The voting is still going on in the Canadian Blog Awards. We still need your vote.

If you’ve already voted, great, you can VOTE once per day! Yes, those are the rules. So what are you waiting for?

Click —>> here <<— and vote for us! The image below give you any additional info you need. :-)

Thanks, and please leave a comment to let us know if you voted.

Book Review: Take Charge Product Management

It’s been a while since I reviewed a book on this blog.

BTW, if anyone wants to review books for this blog, contact me.

OK, enough with the housekeeping, on with the review.

Title: Take Charge Product Management – Time-tested Tips, Tactics, and Tools for the New or Improved Product Manager

Author: Greg Geracie

Published by: Actuation Press, 2010

ISBN: 978-0-615-37927-2


Take Charge Product Management by Greg Geracie, subtitled “Time-tested tips, tactics and tools for the NEW or improved product manager“, is clearly aimed at people with little or no Product Management background.

The book consists of 9 chapters and a Epilogue. Yes, an Epilogue. I’ll get to that later.

The chapters are:

  1. Your Mission, should you choose to accept it
  2. The role of the Product Manager
  3. Key activities to help you succeed
  4. Establish firm footing
  5. Formulate a winning approach to the market
  6. Moving from vision to execution
  7. Product development
  8. Never take your eye off the market
  9. Documenting results

Structure and Style
What’s interesting about this book is that each chapter starts with a short anecdote about people in the fictitious company: Alpha Technology Ventures. There’s CEO Sinclair Jones, VP HR Linda Welsh, Chairman Kevin Knowles, VP Sales Robert Lamp, head of Engineering Alex Wong, and a few other minor characters. But the main character is Sean Knight, a former Sales Consultant who transitions into being the company’s first Product Manager in Chapter 1.

After a short anecdote about the exploits of “newly minted” PM Sean Knight, each chapter continues with additional information to help the reader understand the issues facing Sean and tools and technique to move forward.

For example, Chapter 4 begins with a conversation between Sinclair and Sean. Sinclair gives Sean some advice on how to build a solid foundation in his new role and how to work effectively given the conflicting tensions he’ll have to deal with amongst the different groups in the company. Sinclair leaves Sean with the following advice: Good generals make sure to secure their base of  operations before expanding outward.

The chapter continues with advice on where to find information within a company that can be used both to get a good understanding of the market, customers, products, buyers etc. The list of suggestions includes analyst reports, customers lists, existing presentations, win/loss data, competitive information, defect reports etc.

Each chapter ends with “Tips for Taking Charge”. These summarize and reiterate some of the key points of each chapter.

The Epilogue summarizes the progress Sean has made in his first year as a PM. Sean’s achievements may be slightly optimistic, but they do represent a target to aim for, for anyone in Sean’s place.

First the negatives
While I have absolutely nothing against self-published books, a lot of them suffer from poor typography and graphics. This book is no different. The entire book is set in what looks like 12 or 14 pt. Times New Roman. It looks like a Word document was simply reformatted to fit the smaller page size of a book.

The lack of variety in the font makes it harder to differentiate various sections of text and scan efficiently over the pages. At minimum, the Sean Knight anecdotes should have been typeset differently than the main body in each chapter. Maybe this is a minor point to some, but readability is something that every book publisher should address. Formal publishing houses definitely do.

Some of the diagrams in the book are very hard to read, usually due to the fact that a large diagram has been reduced significantly to fit on a single page.

For example in Chapter 6, there is a diagram entitled Alpha Technology Venture’s Completed Product Lifecycle Management Framework.

This diagram condenses an entire Product Lifecycle (from Strategy to Retirement) across the top, and is broken out (along the side) by  Activities, Owners, Collaborators, Description and Deliverables. There are 12 different columns in the diagram.

To be honest, this is a good diagram and an entire book could be written detailing the individual elements, but each element is so tiny that the diagram simply becomes an eye chart.

Also in Chapter 6, another diagram - the Alpha Technology Ventures Product Decision Matrix Framework – suffers from the same problem.

It’s a table consisting of about 15 columns and 6-7 rows. To fit the table onto the page (remember it’s 15 columns wide!), it is laid out in landscape orientation, using what looks like a 5pt font. The text is incredibly tiny and barely legible.

And now the positives
This book is clearly aimed at the neophyte Product Manager. The exploits of Sean, Sinclair and others at the beginning of each chapter provide context for the reader as they work through the meatier content in the middle of each chapter.

There are a lot of tips and explanations of basic concepts throughout the book. A sidebar in chapter 3 explains Return on Investment (ROI). Another sidebar in chapter 5 explains FTE (Full-time equivalents).

The author touches on many of the common issues and challenges that new product managers — particularly at small companies — face, such as transitioning into the role from another department, the political realities they must face, the daunting scope of the role, the challenge to initially define it, working to be proactive vs. reactive etc.

Each chapter works it’s way through basic concepts fairly well and lays out some concrete actions that a PM can consider.

It’s clear that Greg has lived through much (if not all) of Sean’s experiences himself during his career and is now imparting the  wisdom gained to the next generation of new Product Managers.

In summary
Typography and diagrams aside, I’d say that Take Charge Product Management is a good resource for the new or soon to be new startup Product Manager.

I include the word “startup” because Product Management in larger companies — i.e. with an established Product Management team — would have defined roles and responsibilities, and some level of process (I would hope).

The book is easy to read with a nice casual style to the writing.  And while there is little that is new or truly innovative in the book, there is enough substance that the reader won’t feel they’ve wasted their time.  It’s not going to make you an expert or turn you into a rock-star PM, but if you want to learn the basic concepts before digging into more detailed reading or taking some classes, this is a good place to begin.


Vote for us in the Canadian Blog Awards

Hi, we need your help. We’re a finalist in this year’s Canadian Blog Awards.  Please vote for us.

Click —>>  here <<— OR on the image below.

It will take you to the voting site.

Submit your vote. But do it fast. Voting ends October 26. But, you can vote once per day – those are the official rules, so vote early and vote often!

Click this image to go the voting page!

Thanks, and please leave a comment to let us know if you voted.

Guest Post: 4 ways that Agile methods brought sanity to my company

NOTE: The following is a guest post from Wayne Mulligan. If you want to submit your own guest post, click here for more information.


The company I founded almost 4 years ago,, was acquired last year.

When we were still an independent company we relied on various agile frameworks and techniques to rapidly build and improve upon our products.

We never had a big enough team to do it completely right (e.g. pair programming, etc.) but we made use of a number of techniques that helped us create a great experience for our users.

Our New Home
Well, that all changed when we became part of the Production team (this encompassed design and development for our web products) at our new home: TycoonU, a financial education provider.

This was a much larger company than ours but lacked any explicit processes for planning, deploying and improving on its products.  The development schedule was typically determined ahead of time by the folks in the Marketing or Education departments.  The Tech & Design departments were not empowered to make product level decisions without getting approval first.

When I first came on board, conversations like this one were fairly common:

Jack: So, we’re thinking of rolling out a new course website on October 1st.

Me: Ok, great, but you do realize it’s September 2nd?

Jack: Yeah, and we need it to have….[fill in laundry list of product requirements].

Ok, how would you prioritize each of those?

Jack: What do you mean?  We need them all.

Ok, but given the tight timeline, it probably makes sense to work on the most important features now, add the rest to our “backlog” and roll them out after we launch.

Uhmmm…Backlog?  We need them all…bye.

I’m obviously exaggerating here (and names have been changed to protect the innocent) but you can imagine how the next month would look.

We’d go nuts for 30 days and after that ONE BIG PUSH was over, we’d sit twiddling our thumbs for a while.  And that wasn’t even the worst part.

The worst part was that the concept of rapid iteration and continuous deployment didn’t exist here.  Our products would sit stagnant until someone else gave us direction – and the direction would usually come from inside the building, not our customers that were on the outside and actually using our products.

What To Do?

The company really seemed like it could benefit from employing some basic Agile principles – user stories, rigorous prioritization, product backlog, sprints, etc.  However, as hard as we tried we were never able to institute a full agile (specifically, Scrum) process into the company.  Priorities were constantly shifting. Marketing and the Educators ran the show and the Technology & Design team had very little influence in changing any of that.

So instead of throwing up my arms and just rolling with it — or getting into a protracted battle with the other departments — I hunkered down with our team and asked this question:

What are the primary benefits of an Agile approach to software development and how can we modify some of the existing frameworks to fit this organization?

First Principles

To answer the first part of the question, we turned to the 4 elements of the Agile Manifesto:

  1. Individuals and interactions over processes and tools
  2. Working software over comprehensive documentation
  3. Customer collaboration over contract negotiation
  4. Responding to change over following a plan

The Solution
We then looked at each of those principles individually and thought about how they could apply to our day-to-day.  Here’s what we came up with:

1.  Individuals and Interactions – Originally, when someone from Marketing or one of the Educators would come to us and ask for a new set of features, they’d typically talk about the specific functionality or implementation they wanted (e.g. “We need a forum on this website so our students can talk to one another”).  We’d spec the project out and execute as fast as possible.

However, that isn’t what agile is about.  Agile values the people the software is built FOR not who’s doing the building.

So we began to reframe the discussion around user goals.

Instead of asking about what functions they’d like in the forum, we’d ask questions like:

  • Why do you think this would be valuable to your students?
  • What do you hope they get out of the experience?
  • What goals in the context of their financial education will this help accomplish?

That forced the person making the product/feature request to think about the issue a bit differently.  It forced them to focus on the user and how the user would interact with the product.  And best of all, it forced them to prioritize features and functions based on the value to the user!

We found that once we engaged people in other departments in this way, we could begin to propose solutions to the problem that were often simpler and more elegant than what they originally had in mind.  This allowed for rapid turnaround times, higher satisfaction amongst our user-base and would get everyone thinking about how to prioritize our efforts in the same way.

Once we had a prioritized list of features, we basically had the makings of a product backlog on which future sprints on which could be based.

2.  Working Software
– One of the things my team prided themselves on, was even though we worked under tight, predetermined deadlines, we always had fairly polished deliverables.  The code, HTML/CSS mark-up and even the source image files were all well organized and clean.

On our next big product launch, the team took a different approach.  We began to relax a bit on the elegance of the code and the markup.  We didn’t include time for refactoring in the development timeline.  Instead, we focused on cranking out functional and usable software.

However, we kept a running list on what we wanted to improve upon later on.  This in turn was added to the backlog and would more often than not, become the sole focus of our next sprint.

3.  Customer Collaboration
– This is perhaps what I think bothered me the most about our process.  We wouldn’t methodically gather data and insights from the people we were building our products for.

I mean, we’d put out a survey or two once in a blue moon, but first the marketing guys would go through it, then the Educators and then maybe we’d get access to some distilled version of that data.

So I was ecstatic when we got approval to include a “customer feedback” feature across all of our sites.  Now, we can get access to customer feedback in real time.

Not only that, but we found that people actually wanted to beta test our products for us before they came out.  By showing the Marketing team that people were proactively volunteering to help us test and build our websites, we were able to put together a dedicated Test Group of our customers.

In exchange for early (and sometimes discounted access) to our products and courses, we would get early feedback from our users.  Again, this was invaluable in not only prioritizing features, finding design and usability issues but also in constructing a meaningful product backlog to work off of after our launch was complete.

4.  Responding to change – It’s funny, but the very act of following a framework, like Scrum, too religiously violates one of the core principles of Agile.

So maybe in my desire to impose “our way” of doing things upon our new company, I was being somewhat hypocritical.

Instead of trying to stick too closely to a plan or a framework, I should’ve rolled with the punches from the beginning.

And that’s the biggest lesson I learned here – you can reap all of the benefits of an agile product development approach without following the rules to the letter.  It’s the spirit of the manifesto that counts and not the precise implementation.

The Results
Things have turned out better than I could’ve imagined!

We still operate on tight launch timelines, which tend to screw with our overall sprint cycles (e.g. you won’t see us on 3 week cycles throughout the year, we’ll break it into 5 weeks for a launch, back to 2 weeks for refactoring, then back to 3 week sprints until the next launch).  But our products have improved dramatically.

Our customer retention rate went up by 15% in the first year.

Our relationship with the other departments has dramatically improved.  We’re all speaking the same language now, which is the language of our customers.  Prioritizing products and features has become a breeze, especially now that we have real customers providing us with feedback all the time.

And best of all, the entire team is much happier and satisfied with their work.  We’re able to direct our own production efforts now and we’re also able to provide much more input into our user’s experience on our sites.

So my advice to anyone struggling with similar issues – don’t try to force something into your company that doesn’t quite fit.  Every organization is unique and has circumstances beyond your control.  Observe, adapt and most importantly, keep it about your customers and I believe that only good things will follow.



Wayne Mulligan founded – a white label Q&A platform for investors that boasted NASDAQ as a client.  TickerHound was acquired last year by Tycoon Publishing, an online educator for independent investors.  At Tycoon, Wayne oversees a team of talented designers and developers who are trying to change how individuals manage their money. You can find more of Wayne’s thoughts on his blog:

They’ve seen a mouse, right?

Steve Johnson has a great post entitled They’ve seen an iPod, right? about a new remote control from Sony for an internet TV product. This is it below. I kid you not.

After reading his post, I couldn’t help but think about another similar absurdity. This is the so called “Open Office Mouse” from a couple of years ago. Anyone remember this one? I totally love that plunger thing on the side!

What’s remarkable about both of these is not simply the ridiculous number of buttons, but by their design, it’s clear that the creators of these devices made them in a bubble, devoid of any understanding of who would use them and why.

These two devices tie directly back to the previous post entitled When form doesn’t follow function.

It’s amazing to me that given how much we know technology and the drive towards simplicity, that products like these still make it to market.


Worth Repeating: When Form Doesn’t Follow Function

NOTE: This post was originally published in January of 2009.  It’s interesting to note that almost 2 years later, Aptera has yet to ship any vehicles to customers, and is still is working out a lot of issues with the unique design of their vehicle.

I have nothing against Aptera, but their example goes to show that while a single revolutionary feature — i.e. a claim of 300 miles per gallon fuel consumption — can get you headlines, it takes a LOT more than that to get a product out the door. For those interested in news about the Aptera, this site has a good collection of posts and details some of the hurdles Aptera has encountered.


I’ve written before about frames of reference. That’s the term I use (borrowed from physics) for how we can perceive situations around us differently from others due to differences in context. When building products, our frame of reference when defining priorities is based on previous experience, our objectives and our understanding of (or lack thereof) the target market or user who will ultimately use the product. Lacking any real understanding of the target audience, we default to our own needs and assume (or hope) they apply to others.

In an episode of the cartoon series The Simpsons, Homer Simpson’s long lost half-brother Herbert is the owner of a successful car company. He asks Homer to design the company’s next car; a car for the average family, just like the Simpsons. Homer asks for a number of features on the car:

  • A giant sized drink holder for those “super-slurpers at the Kwik-E-Mart”
  • Tail fins, bubble domes and shag carpeting because “they never go out of style!”
  • Multiple horns that all play ‘La Cucaracha’ because “you can never find a horn when you’re mad”
  • A separate soundproof bubble “for the kids with optional restraints and muzzles”
  • With an engine “powerful like a gorilla, yet soft and yielding like a Nerf ball”


Think this kind of thing only happens in cartoons? While I haven’t seen anything as truly hideous as this car in real life, I recently came across an example of a car that was built by engineers, and apparently for engineers. It’s called the Aptera, and it is an actual electric and hybrid vehicle that is meant for production, with a list price of about $30,000.

The shape of the Aptera is designed to minimize wind resistance. In fact, if you visit their website, you’ll get a brief lesson in aerodynamics and drag. Do I need to know that as a car buyer?


Note the doors are gull-wing in design, but the door windows are fixed. You can’t open them. So much for using any drive through service such as a bank machine or fast food restaurant or toll booth!  NOTE: This issue has since been addressed and new versions do in fact have roll down windows.


And looking at it from the side, imagine the huge blind spots the driver will have both on the passenger as well as driver side. Note that none of the photos above show external rear-view mirrors on the car, but apparently they have added those to the vehicle. There is also a rear view camera system that is meant to minimize the blind spots, but that seems like a workaround IMHO. They’ve optimized for aerodynamics and now need to add features to address usability problems they’ve created.


Now, this vehicle isn’t all bad. It is claimed that the hybrid model will get 300 miles per gallon of gas. Amazing achievement if it’s true, though with crude oil currently trading at about $50 $80 per barrel, extreme fuel efficiency isn’t at the top of everyone’s list right now.

Second it has a number of interior features including:

  • 2 cup holders (the car seats two people)
  • smart phone connectivity
  • driver and passenger airbags
  • side impact beams
  • solar assisted climate control

So, it’s not as hideous as the Homer — no horns playing ‘La Cucaracha’ — but it’s an example of what can happen when products are designed with the wrong frame of reference. 300 MPG is great, but you know what, I’d take 150 or even 100 MPG and a lot more usability.

Aptera, if you are listening — change is a process. Your intentions are great, but there are a lot of changes you’re imposing on your users. The path to success is helping address our problems without requiring us to completely change our frame of reference.


Guest Post: 3 Steps to a More Effective Voice of the Customer Program

NOTE: The following is a guest post from Christine Crandell. If you want to submit your own guest post, click here for more information.


A well run voice- of-the customer (VoC) program can be a formidable source of ideas for new products, enhancements to existing products and untapped uses for underlying technologies. However, despite a genuine desire to effectively incorporate customer voice into product decisions, the execution is often where the obstacles lie.

In a recent study on global strategy, Forrester Research discovered that two-thirds of North American companies have VoC programs, but less than one-third actually make decisions based on customer needs.

Some of the most valuable product ideas emerge from relationships with customers and prospects. But without a consistent process for capturing and utilizing this feedback, the data gets dumped into a black hole never to be seen again.

Often customer suggestions never actually reach product managers, but remain in email, on sticky notes, or between the two ears of individuals who are not compelled to share this knowledge.

For companies committed to turning their VoC programs into a force for market differentiation, the first priority is to plug the leaky communication channels and funnel this information to Product Management.

There are 3 main sources of input for a VoC program. These are:

  • Customer-initiated activities
    This is feedback that is often captured in CRM and customer support systems (e.g. customer complaints, feature requests etc.) and should be integrated with product innovation ideation and idea management capabilities.
  • Company-initiated activities
    These are typically sales and marketing related activities ranging from individual sales calls, to focus groups, user groups and customer advisory boards.
  • Engagement activities
    These are company initiatives explicitly designed to get targeted feedback on products and product direction. These include product management led focus groups, beta programs and customer feedback portals.

Figure 1 – Most companies are not receiving a continuous flow of customer ideas due to a broken VoC engagement channel.

Your Obstacles
Without a consistent system and process for gathering data, product managers are forced to be speculative, to rely on internally generated ideas and to overlook all but the most critical components of customer feedback. “The little things” are often what makes or breaks the product.

Additionally, when a company has invited customers to participate in the co-creation of products, but then fails to act on that data, the company can lose credibility and loyalty with those customers. A typical enterprise has at least 3-4 departments that could be soliciting customers for feedback. An idea-capture system that is part of the CRM system can help integrate all touch points where customers communicate, and then make the feedback visible to constituents across the organization.

Take the following steps for implementing a successful VoC program:

Step 1: Get a Grip on Customer Touch Points
Identify every customer touchpoint within the company, where product feedback could be collected, evaluate where you’ll receive the best quality data and reach out to those department heads. Then work together to build a consistent process for feeding what customers say back to your group. There’s a good chance this will involve using technology to automatically feed a select group of records from each department’s systems into your own.

Step 2: Dive into Your Data
Hopefully by the end of step 1, you’re collecting several times as much customer feedback data as you were before. But, that can be intimidating. Take a dive into your data. Use an intern and software tools to remove duplicates, identify common themes and create compelling product strategies as well as product details.

Stick with it. This customer data offers validation behind product features that would otherwise be removed, modified or changed against the customer’s wants through the decision-making process. Remind executives and other stakeholders that your recommendations are based on what customers asked for. But also be prepared to respond to their needs in different ways and make compromises where it’s practical.

Step 3: The Execution
This is where the vast majority of VoC programs really fall flat. VoC programs need to continue running all the way through the development process, not just in early planning.

In addition to collecting feedback from pre-existing channels with customers who are passing judgment on today’s product, you have to get feedback throughout the development process based on the specific features you are incorporating.

This is why Product Managers must also have their own outlet to customers. No other department will be able to get a response from customers on the details of the features you’re currently developing. Whether it’s an online community, beta customers, or another source, Product Managers must have an outlet to publish product development updates where customers can see them and respond. This way the development team can obtain actionable guidance every step of the way.

“Build it and they will come” or so they say. And they will. It’s spectacular seeing how willing customers are to participate. Many customers will provide deep insights that an analyst or consultant could never obtain, and they do it for free. However, the process requires an attentive ear, an open mind and an analytical approach. If you have 30,000 customers, listening to all of them is no small feat.

I would urge anyone reading this to make a commitment today to get this started, create an action plan and set deadlines. Too often our daily workload prohibits us from doing the strategic work that will make products sell. This is your priority.



Christine Crandell blogs regularly about product innovation on Accept Corporation’s blog The Innovation Jam. Accept provides technology companies with software to that improves profit by helping them build the right products faster.

If you want to submit your own guest post, click here for more information.