Tuesday, July 31, 2007

How a Six-Month-Old Startup Got Bought by Google

Yes, this piece gives advice (based on an actual startup experience) about how to get bought by Google, but it's really just sound advice for any business:
  • Don't focus on getting acquired.
  • Instead, focus on the user.
  • Ignoring limitations lets you tackle problems from a different angle.
  • Don't be afraid to tackle the giants.
  • Pay attention to the details.
  • Have a really understanding spouse.
See the piece for details.

Wednesday, July 25, 2007

Buy a Problem

In my last entry, I described the Buy a Feature innovation game. One of the shortcomings of the approach is that it focuses on features instead of problems.

Unless they are product designers, your customers likely do not know how much a feature is worth to them. What they know - or at least what you can elicit from them - is what problems they currently face and how much those problems cost them.

Before your product designers decide what features to include, they need to know the product requirements. As I've mentioned, requirements are simply a manner of expressing, in measurable terms, the problems that customers want to solve and avoid.

So Buy a Feature can put the cart before the horse. Your team needs to understand the problems customers want solved, and how they prioritize them, before jumping into features. And once your team is considering various features, why do you need customers to prioritize them for you? Your team's job is to weigh the features in terms of how well they address the requirements (which have already been prioritized), not to engage customers in a separate effort of prioritizing features independently of the problems they solve.

Tuesday, July 24, 2007

Buying Features

One of Luke Hohmann's great innovation games is "Buy a Feature":
Create a list of potential features and provide each with a price. Just like for a real product, the price can be based on development costs, customer value, or something else. Although the price can be the actual cost you intend to charge for the feature, this is usually not required. Customers buy features that they want in the next release of your product using play money you give them. Make certain that some features are priced high enough that no one customer can buy them. Encourage customers to pool their money to buy especially important and/or expensive features. This will help motivate negotiations between customers as to which features are most important. This game works best with four to seven customers in a group, so that you can create more opportunities for customers to pool their money through negotiating.
A nice consequence of using this approach is that it gets customers away from the mentality that features come for free. They must prioritize and balance the value of features versus development costs.

If you haven't checked out Luke's book, Innovation Games, I definitely recommend it.

Nonetheless, in my next post, I will discuss an important limitation of this approach and propose a variation that addresses the limitation.

Monday, July 23, 2007

Monitor Your On-Line Presence

If you monitor mentions of your company or product on search engines, in on-line news, or in blogs, you may find yourself manually performing searches on an irregular basis. An easy way to monitor your on-line presence is to use Google Alerts:
  1. Go to the Google Alerts page.
  2. Sign into your Google account (if you don't have one, create one).
  3. Click the 'New Alert' button on the bottom right of the page.
  4. Type the search keywords you wish to monitor.
  5. Select whether to monitor news, blogs, web, groups, or comprehensive (all of them).
  6. Select how often you wish Google Alerts to perform its searches.
  7. Click the 'Create Alert' button.
Then you'll receive e-mail notifications when your on-line presence changes.

Tuesday, July 17, 2007

Your Product Will Be Buggy

No matter how thoroughly you test your product, no matter how many quality control measures you put into place, any new or significantly-enhanced product you release will be buggy.

Some good quality control measures include:
  1. Your product manager gathers realistic usage scenarios from prospective and existing customers.
  2. Your testing team maintains a suite of regression tests, adds to them as tricky new scenarios come to light, and runs the tests on a regular basis.
  3. Your developers maintain unit tests and run them on a regular basis.
  4. Your developers review each other's designs and code.
  5. You release beta versions of the product to customers.
Yet even with these measures in place, your product will almost certainly contain defects. Part of your release plan should be to put mechanisms in place to efficiently process defect reports, fix them promptly, and enable users to obtain the fixes as quickly and painlessly as possible.

Tuesday, July 03, 2007

iPhone: Distinctive and Inviting

My friend Tamara got an iPhone over the weekend, and I got a chance to play with it Sunday. After watching her use it, listening to her comments, and trying it for myself, I concluded that the iPhone is distinctive and inviting.

The iPhone is distinctive in the sense that I have never seen another phone that simultaneously is sleek, has a large and bright screen, and has a fingerable touch screen. My 8525 has a fairly large screen and a stylus touch screen, and it is more powerful, but it is by no means sleek. It looks clunky in comparison to an iPhone.

The iPhone is inviting in the sense that, while not necessarily easier to use than many other phones, the phone's user interface is innovative and stylish. You want to hold the phone and use it if just because it looks so "neat".

That said, aside from its distinctive and inviting look, I see little reason to buy an iPhone. And it still remains to be seen whether the iPhone will be a success in the long run.

Monday, July 02, 2007

Use Cases for Sales Enablement

The sales folks in your organization need to connect with customers by addressing their specific situations and problems. Arming sales with use cases and scenarios can help.

The idea is to document use cases and scenarios for all situations that a qualified lead might face. When a sales person is on the phone with a prospective customer, she then can not only tout benefits of the product, but she make those benefits tangible and clear by applying them to the prospect's situation.

Fleshed-out use cases and scenarios contain the following information that is critical to a sales person interacting with a prospect:
  1. Description of the functional goal of the user. The name of the use case/scenario should convey what the user wants to accomplish. An explanation of the context and the reasons is also helpful.
  2. User interactions with the product. The step-by-step description of how the user will interact with the product to achieve her functional goal.
  3. Preconditions and postconditions. Conditions that exist before and after the user has interacted with the product as described in the use case/scenario. Preconditions and postconditions indirectly capture the nonfunctional behavior (usability, performance, etc.) of the product.
But keep in mind that most of what your sales people should be doing is first asking questions to understand the customers' situation, problems, the implications of those problems, and the need/payoff associated with the problems. Only then can they identify the use cases and scenarios that are truly compelling to the prospect.

Laura Patterson has more on use cases for sales enablement here.