All over the web and in all the product management communities, there are articles and discussions about gamification. If you’ve been offline for a while, gamification is about applying design and development efforts to software in a way to make it more engaging, more “fun.”

Not only have whole applications been born under the premise (i.e. Foursquare), but gamification has also had great impact in some of the more traditional business software, (ie. Salesforce.com) allowing for more interaction and amusement when performing daily tasks.

I’m all about having more fun in my interactions with technology, and can truly appreciate making the more mundane less so; but, I believe sometimes we have taken the concept of gamification too far.

Not every piece of software or every interaction within should be designed around fun. Stanford professor Elizabeth Corcoran, in her book on the subject, “The ‘Gamification’ Of Education”, suggests that the gamification of businesses and virtual worlds is creating an expectation among people that real-life interactions follow simple mechanics and some disillusionment when they do not. Are we making our software more of a toy than a productive tool?

I recently heard of a software company’s UI meeting, held to introduce the upcoming planned release to the internal audience, where the  discussion quickly went from what the planned for now to the planned for later. In the “planned for later” talks, the designers were sharing their vision for the upcoming UI changes, which were focused on including more opportunities for social interactions. The problem? No one had talked with more than 1 or 2 current customers to find out if this is what is truly needed or wanted.

Conversations need to start with the market, not just customers. Does your market want to play a game when they are in your software? Will it help them do their job better? More effectively?

Luke Hohmann, with his company Innovation Games, does great work in promoting playing collaborative games with your customers to build  engagement. He states that engaging customers in a well-designed Innovation Game frees them up from the constraints of typical focus-group sessions and delivers deeper, more accurate information than is available through online surveys or other tools.

There are some very successful elements that need to be copied.  Gaming elements do and should belong in SOME software. Luke’s reasons and use make sense. In consumer-facing sites, I support using gaming elements to make the site more engagement, building more loyalty, etc. In business programs,  I can no longer remember the “old” training programs where you didn’t even see your status on the module much less your achievement. Gaming made training more fun. But, once you start entering the enterprise software realm, gamification is an area that needs to be evaluated carefully.

Gamification elements that are added in by designers because they are the latest and greatest, will quickly get subjected to the sideline and prove to be a waste of your time and effort. In the competitive software market, time and effort need to be focused on those areas which deliver the differentiation. And, it might not be about the game.

(Please share this on Twitter, LinkedIn and even Google+: “Not Everyone Wants to Play Games” by@jidoctor: http://wp.me/pXBON-36h #prodmgmt #gamification”)

Related posts:

1. Games executives play: Guess what's in the envelope
2. Book Review: Innovation Games
3. I clicked "Play", mommy
4. How to be a GREAT Product Manager (part 4)

You know you’re a Products Geek, when you find a show like Pitchmen appealing.

Pitchmen, on the Discovery Channel, is a behind the scenes docudrama about infomerical marketers and how they  identify products to promote, develop the pitch and then take the products to market.

The show stars the late Billy Mays and Anthony Sullivan, two very successful and well known television direct marketers.

While it’s very easy to brush these guys off as selling gimmicky items to uninformed consumers, there are lessons to be learned from watching these guys operate.

And that’s what I like about the show. It presents some of the discipline and process they follow for the products they market and sell. Here’s a list of some of the behind the scenes work they do.

1. They look for problems that a lot of people have.

• Stain or smell remover: Yes
• An acoustic shark repellent: No

2. They test out the products and validate they actually live up to their claims.

• Can the odor remover get rid of foul smells from hockey equipment?
• Can a vertical grill actually cook as well as a traditional horizontal grill?

3. They listen to others carefully, getting feedback from potential users of the product.

• For a self-rotating pool side lounge chair, aimed at removing the need to manually rotate a chair to get optimal exposure of the sun, they enlisted some swimsuit models to test them out. After the trial, they not only asked what they thought of the product, but asked how could the chair be improved. One of the testers suggested cup holders.  Not a bad suggestion.

4. The benefits of the product have to be clearly demonstrable with a number of use cases.

• For a food grater, they grate garlic, chocolate, cheese, citrus zest and other foods. The objective is to present a broad number of real use cases  to show utility and value. This is clearly an area where technology companies need to improve when thinking about how they demo their own products.

5. They always try to find at least one “Wow!” aspect for each product.

• For a shoe insert product that claims to eliminate impact from running or other sports, they put their hand under a pad made of the same material as the insert, and then hit the pad with a hammer. Then they took their hand out and wiggled all their fingers to show they were undamaged. Can you say “Wow!”?

6. They craft the messaging and the pitch, being very particular to the words they choose.

• Whether via rhymes or alliterations or carefully crafted wording, the right word at the right time can make a big difference in how a product is perceived.  For example, with a product for grating food, the lines “grate cheese with ease” and “for zest it’s the best” are used. Don’t think these stick in people’s memories? Remember that line from the OJ Simpson trial? “If the glove doesn’t fit, you must…”

7. They ensure price points that will be appealing for their audience.

• With a vertical grill product (think of a big single slice toaster that grills burgers, steaks etc. vertically) they went to one of their partner companies who tried to source a manufacturing partner that could build product cost-effectively enough that they could sell it for $50.  The partner couldn’t bring the price point low enough and so they said “No” to the product, even though it met all their other criteria.

8. They are data driven business people.

• While they may come across as shady marketers, they are clearly rather sophisticated (and successful) in what they do. They test out their pitches in local markets, measure the results, adjust their pitch, and test again. When they go national, they are very confident that they have something with mass appeal that people will buy.
• This is probably the most important lesson that Product Managers should remember. They definitely follow the “Nail it, then scale it” mantra.

Overall, I find Pitchmen to be a bit of a guilty pleasure. I’ve got it scheduled for recording on my PVR. Even so, it is educational and every episode reminds me of basic marketing principles that have broad applicability and value.

Saeed

Related posts:

1. Worth Repeating: 8 Lessons we can learn from Infomercials
2. Innovation Lessons from Scott Cook
3. What can we learn from Cassatt’s demise?
4. 5 benefits in thinking about revenue models right from the start

In just about 3 weeks, we’ll be hosting the 2nd ProductCamp in Toronto. Last year, at the first event, over 100 people came out to participate in a day of very engaging discussions and talks about topics on product development, product management, marketing, innovation and more. Some of the presentations and notes can be found here.

Pre-register today!

There are already about 150 pre-registrations for the this year’s event!

If  you want to attend, click here to add your name to the list.

It’s free to attend, and lunch is included(!),  so come out and spend a day of engaging thought and discussion with others like you.

Suggest a Session (or Vote for your Favourites)

In the spirit of BarCamp, the day’s sessions will be voted on at the start of the ProductCamp on Oct 4. But if you want to suggest a session, or want to present one yourself, you can do so in advance.

Click here to see the sessions and vote on them, or to suggest new ones of your own.

Become a Sponsor!

A number of companies have already agreed to sponsor the event, including:

• The Ted Rogers School of Management (providing the venue)
• Pragmatic Marketing
• SevenL Networks
• Greenscroll
• MI6 Agency

Also, our own Alan Armstrong and his jazz band will play live at the end of day reception.

Thank you to all of these organizations. But we’re looking for more sponsors. Sponsorships are used to pay for lunch and t-shirts for all the participants, as well as materials, signage and other expenses that are incurred.

Your organization’s name and logo will be prominently displayed on the ProductCamp website, on the day’s materials, on the t-shirts, and significant mention will be made of the sponsor’s during the day.

If you’d like to become a sponsor and gain visibility with innovators in the Toronto area, contact us:

• productcamptoronto at gmail dot com

Volunteer

We’re looking for volunteers to help with some of the logistics during the day. If you’re interested in volunteering,  you can indicate that when you register and someone will contact you.

Twitter – #pct2

Finally, look for the #pct2 hash tag on Twitter. We’ll post announcements via Twitter ahead of the Camp and hope to have some live updates on Oct 4.

Looking forward to seeing you there.

Related posts:

1. Join us this Sunday at ProductCamp Toronto
2. Announcing ProductCamp Toronto 2009
3. ProductCamp Toronto — Date AND Location
4. ProductCamp Toronto – It's on!

We spend way too much time in our companies designing, measuring, and enabling, the Sales Process.

Every time you hear those words (Sales Process), I want you to ask a question: Wouldn’t it be more useful if we talked about the Buying Process?

Does this difference – between Sales process and Buying process – sound like hair splitting?

It’s not. You can make up a Sales Process. You have to talk to actual buyers to map the Buying Process. When you do that, everything will change.

- Alan

Related posts:

1. Sales Axiom: Sales is not customer service
2. How to Structure an Effective Go-To-Market Process
3. Can we chat about sales introductions?
4. Aligning Sales and Marketing

If you haven’t checked it out, take a look at Cindy Alvarez’s blog: The Experience is the Product.

She recently posted a good article entitled:  Getting beyond beta: Measuring your audience breakdown.

Given the focus of her blog, the article describes some simple ways to analyse website traffic and conversion for a hypothetical ‘sock-matching service‘. Yes, that sock-matching service!

Cindy takes a straight forward approach at audience breakdown and provides some good advice and links to useful online tools to help address the problem.

While many product managers aren’t charged with specific focus on usability, when thinking about user loss and conversion ratios on the Web, there is a clear business case that can be made on the impacts (positive and negative) of good or bad usability respectively.

Great Post!

Saeed

Related posts:

1. Open Question: How and When do you define usability requirements?
2. Usability as a strategic weapon. Lessons from Wesabe’s founder
3. Oh yeah? Compete with this!
4. Socks in awe: Customer interviews vs. User observation

I had to share this with you. While more hardware than software, this video only goes to show you that it’s always important to rehearse your product demos so that no surprises occur, possibly impacting sales, or even worse, your own well being!

View the video before reading on….

Now what I honestly don’t understand is what happens AFTER the accident.

No one rushes to assist the person and see how seriously he’s hurt.

Almost 20 seconds elapses with the cameras rolling, and the demonstrator describing his injury, before another person appears on camera. And instead of attending to the injured man, he looks at the camera, and somewhat jokingly states that emergency surgery may be needed.

Talk about dedication to the sales process! And don’t think this is just a one time incident. Here are a couple of other bad demos caught live.

Saeed

Related posts:

1. What's the deal with tradeshow demos? (abridged and full versions)
2. And another thing. Software demos need serious help
3. Doing Better Demos

In part 5, I showed how you can begin to decompose the areas where teams, particularly Product Management, provide key deliverables to other teams. Here’s what the heat map looked like for Product Management across the stages of the development cycle.

(click to enlarge)

For each colored element in the heat map, a list of deliverables and dependencies for that team at that stage of the cycle must be defined.

One important note here. Even though the chart above lists discrete stages in the development cycle, the stages can and likely will overlap in time. For example, Pre-Beta, Beta and Post-Beta all occur during the Product Development stage. And the Sustaining column is a set of ongoing deliverables that occur throughout all of the other stages and feed into stages such as Product Definition.

So, if one were to take a stab at listing the key deliverables at each stage of the development cycle, it could look something like this.

(click to enlarge)

I say “could look something like”, because it will vary somewhat from company to company, and possibly even from product to product. For example, A hardware product, e.g. an appliance, will have different deliverables at certain stages than a client-based software application. And the client-based software application may have different deliverables from a hosted SaaS application. Having said that, the stages and deliverables listed in the chart are relatively generic and should apply in many circumstances. And finally, some of the items may better fit in other columns depending on the company and the specifics of the situation. e.g. demo creation may take place later in the development cycle, closer to launch, may not even be a Product Management deliverable in certain companies, or may not even be needed at all!

In the context of the Information Supply Chain, when thinking of deliverables, there are upstream dependencies and downstream dependents. Upstream dependencies are any deliverables that must first be completed by yourself or others, in order for you to create your deliverable. For example, a good Product Requirements Document (PRD) might depend on the existence of a Market Requirements Document (PRD). Thus the MRD is an upstream dependency of PRD. Conversely, for every deliverable, the downstream dependents of the deliverable must be identified and documented. e.g. For a PRD, the downstream dependencies can include Functional and Design Specifications created by Engineering and Product Description and Overviews created by Product Marketing.

Now let’s look at the first column and drill down some more.

It has three potential deliverables:

• Statements of Direction
• Market Requirements Document
• Product Roadmap

Each of these needs to be defined and the dependencies (upstream and downstream) need to be identified. Luckily for Product Management, there are very few upstream dependencies in this case. Here’s the text for the Statements of Direction:

As you can see, this is a clear and succinct definition that describes the intent, general contents and consumers of the document. In this example I’ve added the NOTE to show an explicit downstream dependency of a Statement of Direction.

Here’s the definition of the Market Requirements Document. This should be familiar to most, if not all of you.

And finally the Product Roadmap:

So there you have it. The first column of the Deliverables table is now defined. The task for you is to go and try this on your own for other items in the table. Pick a couple of them and work on the definition, the consumers and the downstream and upstream dependencies. Feel free to to post some of them in comments on contact me if you have some questions.

It’s important to work through this exercise within your own company. Explicitly understanding not only what you need to do, but who you depend on and who depends on you across the stages of the development cycle is a very important exercise. I can almost guarantee that you will find a few surprises and challenges as you work through the process.

Saeed

The rest of the series
Product Manager vs. Product Management (part 1)
Product Manager vs. Product Management (part 2)
Product Manager vs. Product Management (part 3)
Product Manager vs. Product Management (part 4)
Product Manager vs. Product Management (part 5)
Product Manager vs. Product Management (part 6)

Related posts:

1. Product Manager vs. Product Management (part 4)
2. Product Manager vs. Product Management (part 5)
3. How to be a GREAT Product Manager (part 5)
4. Product Manager vs. Product Management (part 3)

So, a few weeks back, a number of Product Management bloggers were invited to participate in a “blogfest” (blogapalooza?), responding to Steve Johnson’s post entitled “Why Demo at Tradeshows?”

Both Ethan and I responded to the call.

Having said what I said — give me the opportunity to have a meaningful one-on-one conversation with a valid prospect, and I’ll certainly trade a quick demo for it — I’m a bit surprised that I recently attended a small summit and tradeshow (200 attendees), and in two days, had a number of conversations with a number of individuals at our small “demopod”, and never once did I show running software.

A few key Powerpoint slides and references to the product brochures and data sheets were all that was needed to explain what we did, answer questions and scan their badges.

So, on one level, I admit that Steve (and those who agreed with him) had a point about tradeshow conversations. But on another level, I must also say that the small size of the show was a factor. Many of the people were more interested in the iPod we were giving away versus the software we had to sell.

So, perhaps the attendees read Steve’s article and agreed with him that they didn’t need a demo, or perhaps they were simply preoccupied with the end of the quarter, or maybe they wanted a demo, but because we never offered one, they didn’t muster the courage to ask. Or, maybe there was another reason, but in the end, I noted, somewhat surprisingly that after two days, no demo was presented. A first in my experience.

Saeed

Related posts:

1. What's the deal with tradeshow demos? (abridged and full versions)
2. Why Demo At Tradeshows?
3. How to be a GREAT Product Manager (part 5)
4. Why I hate PowerPoint

A post today on Adaptive Path’s Blog seems apropos to the discussion of tradeshows. Want to do a better demo? Learn the secrets of pick-up artists!

Related posts:

1. And another thing. Software demos need serious help
2. Really bad product demos
3. What's the deal with tradeshow demos? (abridged and full versions)

So I have to go with Saeed here in response to Steve’s posting on tradeshows. Just because a lot of companies handle trade shows badly doesn’t mean they’re worthless. Most companies can’t do email marketing right either; I would not suggest that you stop emailing customers and prospects.

But before we think about what to do at the trade show, let’s review what a Product Manager can get out of a trade show. Two things: one, leads and two, conversations.

Now, leads may not be your direct responsibility, but everyone needs leads. Are trade shows the cheapest way to get leads? Nope. Are they the best way to get leads? Nope. But unless you generate more leads than your salespeople can handle, you need more leads. Even if you have too many leads, how many highly qualified leads are coming in through your other lead generation channels? (The answer is never enough!) Web- and email-based marketing is the #1 source of leads for many B2B companies and I can come up with plenty of ways that companies do web and email marketing wrong. That doesn’t mean they should stop doing it.

You need to have an ecosystem of leads, just like you need to have customers in more than one region or vertical market. And trade shows remain a good way to get new leads. I hate scanning badges as much as anyone, but it works.

Also, if you can’t prove that trade shows are generating quality leads for you, then that’s not the trade show’s fault. Implement close-loop leads tracking! You have a CRM system right? Creating a campaign in Salesfore.com and seeing how many opportunities result from it isn’t rocket science.

Second, conversations. A trade show lets you have longer, more fully engaged conversations with both customers and prospects. Prospects are key here – when was the last time you talked to someone who was actively looking to buy a product like yours but wasn’t yet in your company’s sales funnel? Talking to prospects is so important because if you only ever talk to customers you’ll never find out about what the people who decided not to buy your product think. Prospects can decide not to even consider your product or service based on your positioning, without ever talking to a salesperson. I have yet to find a better venue than a trade show to meet these people and talk to them.

Conversations at trade shows are also more casual and relaxed because of the whole circus-like atmosphere of the show floor. (Being at a circus is great, as long as you’re not one of the clowns). Customers have come up to me and said “I love your product! I use it every day!” I rarely get that sort of enthusaism over the phone during customer calls. Customers have also come up to me and said “I like your product very much. There are twelve things wrong with it. They are…” - I heartily recommend doing a few trade shows in Germany because you will get this kind of feedback from more than one person. It’s great. When you work in enterprise software (my experience has been in development tools and IT management tools) you rarely get to have an animated conversation about the strengths and weaknesses of your product. The development team has never actually used the product and my wife and friends don’t really understand what I’m talking about when I try to explain what I do. Trade show conversations have provided me with months’ worth of stories and user feedback that I trot out during requirements planning sessions.

So, can you do trade shows wrong? Sure. Any marketing activity can become a mindless exercise if you lose track of what your real goals are. But we need to do trade shows.

So, why demo at trade shows? Come on – people need something to look at. Imagine going to an auto show where there was nothing but booths and flyers about all the hot new cars. (Let’s ignore the booth babes for a second. Besides, I haven’t seen a booth babe in years at the Toronto Auto show. I think they may be extinct north of the 49th parallel)

The demo isn’t the goal – it’s just a tool to get people’s attentition. Entrepreneurs talk constantly about honing their elevator pitch. There better be more to your business plan than your elevator pitch, but that’s what the demo is at a trade show. It’s the shiny, animated prop that backs up your elevator pitch. Actual software that’s more than just canned Powerpoint slides says that you have a real product that goes with the pitch. Right or wrong, this is the bar that trade show attendees want to see before they’re going to stop and pay attentition to you. And once you have their attentition, you get to do the two really important things: scan their badge and have a conversation.

As a side note, one product I demoed at trade shows was a web-based marketing automation system. It was next to un-demoable. It worked great, but it was challenging to develop, deploy and track an integrated email marketing campaign in five minutes. (I probably could have done it in ten minutes ). But as I went through the pitch, everyone wanted to see something. One person wanted to see reports, one person wanted to see how to compose email, someone else wanted to see how the automation system worked. This was really a polite way of saying that I was full of sh*t and that there was no such product. My “demo” didn’t really show all that much but it proved that I had a real product, which made my message a lot easier to accept and remember.

Related posts:

1. A no-demo tradeshow…
2. Wither Tradeshows?
3. What's the deal with tradeshow demos? (abridged and full versions)
4. And another thing. Software demos need serious help