Congratulations Boxee, You're Unusable

I've followed the developments of Boxee since soon after I saw them at NYTech meetup and their unrelenting hype began (with considerable fuel added to the fire by Fred Wilson and his business interest). Let me be clear: I am a champion of the goal they are seeking which is to move multimedia entertainment consumption off of expensive proprietary cable onto the Internet. As many of my friends know, I have gone to great pains to create an Internet-only setup at our new house. I see the challenges of this first hand and in my professional pursuits.

Now onto the recently launched Boxee beta. I tried (and quickly stopped using) their horrible "alpha" last year given stability issues and a UX that made Windows 3.1 look like a revolution. Thus, I waited for their "beta" (which, by the standards most others use in the industry, is probably the equivalent of an internal alpha). I was even directly told by Fred Wilson, after listing my issues with the alpha, to "just wait for the beta as the UX is much improved".

Well, its here and, yes its prettier and they have a new home screen that bubbles content they think is interesting to the top but this product is incredibly unusable for these reasons (and I'll skip over the installation crashing and other setup issues in the hope those are bugs are worked out):

1) Discovering content: The biggest problem with Internet consumption of media is discovery. Its all over the place in different formats with different levels of protection. Boxee's aim is to unify that into a big screen viewing app. After you start up, you are presented with big "Music", "Movies", "TV", etc icons. Great, let's get watching. Except that when you go into one of those silos you get a generic config type screen saying its scanning your HD for pertinent media and you can add other folders. What the hell? This new media order is about online consumption not my local HD. Here's a market data point Boxee folks: I have 0 TV shows and movies on my HD and don't plan any. I'm not unlike most people who have not gone to the trouble for the small value of ripping DVDs or getting bilked by online downloading. Yes, I did rip a bunch of CDs for music but now all of my music consumption is from Internet radio. When I go into TV I should see Internet TV sources...local is secondary.

1a) And, yes there is some arcane search to find Internet content. TV is a passive medium, I want to browse and not by what you "feature" as important. How about by source (where content comes from is still important), topic, genre, etc. How about continuing the channel paradigm where I define the channels. I'm in the mood for Comedy and thus those sources are in a channel...sports, etc. How about bubbling my favorites to the top (not just my queue).

2) Mysterious errors, terrible performance, and blank screen: I was prompted to write this post because, in my frustration in trying to discover content (see #1), the only way I could find anything was to scroll through their "Featured" section. I saw South Park and figured I'd give that a whirl. I first get a blank screen saying "Some content might be geo-blocked..." and then nothing. No more info, buttons, etc. I wait and then just go back to the home screen. Suddenly a modal pops up with "South Park" at the top but the screen is blank. As I'm writing, this has now been up on the screen for 10 minutes and Boxee is spinning my hard drive feverishly. In addition, I have had errors and failures on the Netflix app, Shoutcast, and others so I can't use them. These are things you promoted to me and you can't even get them to work? Thus, even venues for desirable content that I've been able to locate don't work. 15 mins in and 0 content consumed.

3) Not usable with a mouse: I am still shocked that Boxee is generally unusable with a mouse. I don't have to describe how bad this is. Just use it for 5 mins with a mouse and you'll see. Guys, even media PCs are still mostly controlled by a mouse not a remote. I have both and the Media Center remotes are generally crap and, given its also a PC, I need a mouse to do most anything productive. And, with hybrid devices like the Loop out this is reinforced. Its treated and works as a mouse does not a remote. Personally, I believe this will be the direction for couch-input for PCs. Make it work properly with a mouse. The only way it would reliably work is to use the Boxee app on an iPod Touch. A neat innovation but not a generalizable solution.

I could keep going but, until these issues are addressed, the rest is moot. There's no way any reasonable person would be proud of this product. Do you even have any product management over there? Come on, get your act together or calm down the hype and only put out a product that's usable. If you think this is reasonable, then I suggest running with your hype and bells and whistles and sell soon as you won't be a market leader with a product like this. At some point Apple, MS, and others in the space will get their act together and/or startups like Clicker will fill the utility void we're missing in a low-fi way (like what they're doing over there with discovery and simple web UX).

I want you to do well. In fact, we need you to do well to break the cable sandbox the way the carrier sandbox is now eroding. The frustration is that products like this only reinforce the value of cable. I won't be using your product until you get your shit together.

Fred, you're passionate about this space. Be honest with your investment and give them the kick in the ass they need here. I'd be furious if I had funds in here.

Agile PM: Problem-Solution Statement

A key element of the Drivers phase is our Problem-Solution statement. This can and should be a simple description of the high-level problem (need), whom we’re solving it for, and what the solution is. An update to our earlier example (we’re able to refine after doing the concept):

Mobile devices are now ubiquitous and are a key (if not most important) way for customers to access local business information. Retail businesses without a mobile presence face losing customers or not gaining potential new ones. However, creating and maintaining a mobile site/app is complex and cost prohibitive for most small businesses with current solutions. Our solution would allow for quick repurposing of web content for all current mobile platforms with no technical expertise and a low-monthly fee to host and maintain it.

This statement defines our customer (small retail businesses), our problem (mobile apps/sites are complex and expensive), and our solution at a high-level. Two of these elements often need additional probing and detail. First, we need to consider both a market (quantitative and qualitative) customer definition and a behavioral (attitudes, needs, and behaviors) customer definition. I find that in larger companies a marketing group often does the market definition with quantitative data segmenting the customers and qualitative psychographic profiles. When done well, these are very useful to the agile product manager. It forms a baseline of data to test and support your product definition. However, these are often utilized solely at the expense of a complementary behavioral definition (personas) often created by interaction designers (NOTE: Lane Halley gave a talk last night at the NY Product Management Meetup about the relationship between Interaction Designers (and what IxD is) and Product Managers in an Agile world.)

Ironically, in smaller companies, I find that the opposite is often true. Mostly it’s due to the rapid nature and lack of resources to do formal market studies. The entrepreneur/visionary lays out a vision and within that are nuggets of personas of the envisioned customer. This is also useful but can be off base without market support. You be the own judge of how much you need of each of these but I always suggest some level of both are important. Don’t let the data heads solely drive who you are targeting and the visionary tell you the customer without real market support.

The second issue that needs to be delved into is our solution definition. Ultimately, this will lead to what we build and deliver. One technique that Agile uses is User Stories [link]. These are meant to be simple, light-weight, specific definitions of what, from a user perspective, one wants to do with the product. Some advocate these in lieu of use-cases. I actually think they’re quite similar in purpose just different in structure. However, I do advise that top-level user-stories are done at this point for a few reasons:

• It makes you put on the table what you think you are building early in the process so there is little room for misunderstandings (esp. with management).
• It brings in the development and design teams early in the process to review and contribute (NOTE: the PM should write these not developers or designers).
• It mitigates risk further by forcing you to think more comprehensively about the product feature set early on and possibly some additional research into key features.

Some user stories for our example might be:

1. As a small business owner, I want to be able to list my products/services, offers, and actionable contact information on a mobile device
2. …, I want to allow people to subscribe to updates from me
3. …, I don’t want to need a developer or designer to update my mobile site/app
4. …, I want to reach as broad a base of customers as possible while maintaining a rich experience

One good technique is to write them from the user’s perspective. You don’t have to do that but I find it’s a good way to keep focused on the customer need. I’ll defer to the various Agile techniques for how to go about gathering, noting, and representing these but user mapping is an interesting discussion.

Agile PM: Drivers

You’ve decided that a concept passes muster to be further vetted in consideration of passing it into Specification and Development. You took input from multiple sources on the concept, tested it against your Product Framework, brainstormed and, perhaps, prototyped it. The team determined not that this concept would be implemented, but that it was interesting enough and possibly a priority to enter the Drivers phase.

This is the most vigorous phase for the product manager. This is where you make the case for a given feature (or set of features) to justify and set a priority and focus. The goal is not to get the feature green-lit. The goal is to do the proper level of vetting to be able to assess the priority based on the business case. As we’ve discussed before, the PM must act as objective traffic cop and not with an agenda to push a feature through, even if this is a concept you developed. If the case isn’t there, don’t ignore that. Remember, a feature might not pan out as a priority right now, but since you put it on the Feature Chart, it’ll be considered for future development.

The elements of the Drivers phase are probably where the greatest gap exists between formal product management and informal agile development. Agile wants less documentation and formalization up front in order to iterate on the feature. The problem – and thus the gap – between these two approaches is that PMs are often in the formal camp since they were trained that way and want to retain some control of the specification. I’ve seen cases where Agile dev teams only take a lose definition of the feature in “user stories” and rapidly iterate to an off base result. This is inefficient. I agree with PMs who want some level of specification and we’ll cover a balanced approach to that in the discussion of that phase. However, it’s key that the concept business case be developed further before specification and the PM must be wise in determining the degree. Here are the key elements of the Drivers phase and some discussion of when and how they should be used:

• Problem-Solution Statement: This is the most important element of a feature definition and always should be developed. If we do not know our problem and for whom we’re solving it, we inevitably won’t be successful. It can be as simple as a sentence or two that elaborates a customer definition and user stories. In our previous example, we’ve did a first pass of this: “our small businesses want an easy way to publish updates about the company to their mobile sites since the sites are mostly static and require technical work to change them today. We could enable them to connect an existing RSS feed (or tell them how to create one) where we scale the content for mobile devices with alerts out to their customers for a fee.” If this were a small feature, this might be sufficient. However, since this looks like a bigger feature set, I’d go deeper on a customer definition with what type and size of small businesses and then some specific cases for how this solves their problem.
• Business Case: The business case detail is optional or, to put it another way, the degree to which it should be developed should vary by the scope of the feature. However, I often find when these are not rigorously part of the process, they fall by the wayside and it’s the third most common way (after no problem statement or requirements) that a feature misses the mark. To support the case, try and get some market data to validate the approach. Too often, this is left up to the “gut” feeling of the concept sponsor. Some objective data allows everyone to evaluate the features appropriateness. How will this feature come to market or how will it affect our current go-to-market? In many cases, there will be no changes. However, be it intended or not, features can suddenly open up the doors to new channels or close them if you suddenly compete and that needs to be taken into account. What are the measurement metrics for success of this feature? How does this affect and relate to the competitive landscape?
• Risk & Prioritization: A key new tool in the Agile PM process is an ability to quantify a risk and prioritization profile. How much have we done before green-lighting into Specification to mitigate the risk? What are the key business drivers for our features so that we can evaluate each new feature to prioritize it?

There is a lot here and each will be covered in more detail in upcoming posts. However, the key takeaway should be that the PM needs to embrace evaluating the drivers for a given feature and have the discretion to know how deep to go. The goal should be to provide sufficient information to put in front of decision makers making them comfortable either moving it forward or parking it on the Feature Chart for future consideration.

Agile PM: The Feature Chart

Most technology companies use “product roadmaps” for both internal and external management of where they are headed with their various offerings. It is believed that these are useful to ensure everyone knows where the product is today and where it is going. In my experience, product roadmaps suffer from several problems:

• Unsupported: Trying to predict future feature sets on an arbitrary timeline that has not been vetted by those who are implementing the product means there is little justification behind it and what you see today is rarely reality in the future.
• Rigid: Trying to incorporate changes is difficult and can throw the process into disarray and may require other features are removed to stay on the same timeline (to someone’s dismay).
• Not Utilized: Those working on the product only focus on the current implementation knowing that anything in the future will not likely happen thus rendering the future information baseless.

PMs often use roadmaps to guide the team toward a desired feature even when they know it has not yet passed the scrutiny of the parties involved (or been through the process). How often have you seen a feature on a roadmap that’s always one or two releases away and is never prioritized?

In Agile PM, I use something I call a Feature Chart to better meet the needs of product managers that does not suffer from the same drawbacks. Product roadmaps can be useful and the Feature Chart can be flattened to “time slice” it at any point to produce a roadmap of where you currently are. I think this is more for external parties who need to know your plan and less for internal management.

The feature chart is based upon the priority ranking we introduced in our last post: Definitely (or in Specification/Development), Likely (in Drivers), or Maybe (in Concept). You now have a direct mapping between your phases and what has passed through the process gateways. However, they are not rigidly associated with a particular time or release. That is taken care of by the project plan and iterations (by whoever is managing your Agile development) with input from you. As we discussed, when a new concept comes up, it gets scrutinized and ultimately placed on the Feature Chart. If it isn’t something that is going to be pursued then it stays outside the rings in the “Maybe” zone until it is designated to move forward. If a concept moves into Drivers where you’re going to put together the business case then it moves to “Likely”. If that business case (to be covered in a future post) is approved then it moves to Specification and into the inner “Spec and Dev” ring.

The chart breaks the product up into logical modules. This is always customized to the specific business and product. I strongly suggest using three general areas as features that might overlap can be placed on the intersection and each module touches the others. Two also works but four or more break that down. Here are some examples of the modules that I’ve used (taking into account business goals as well):

• Integration, Customer Acquisition, Core Features
• Content, Customer Acquisition, Core UX and Integration
• Hardware, Software & UX, Integrated Services

In these two cases, all features fell into one or two of these buckets and were placed accordingly on the Feature Chart. Let’s continue our example and place a few ideas on our chart. In our last post we had a concept that was “our small businesses want an easy way to publish updates about the company to their mobile sites since the sites are mostly static and require technical work to change them today. We could enable them to connect an existing RSS feed (or tell them how to create one) where we scale the content for mobile devices with alerts out to their customers for a fee.” On our Feature Chart, we’re going to break this down into manageable features as: “UI to connect RRS feeds”, “Instructions on creating RSS feeds”, “Algorithm to scale RSS content”, “Send alerts to mobile devices via SMS”, and “e-Commerce module to track and charge for messaging”. Let’s say that we decided to move the RSS part into Specification, the e-Commerce part into Drivers, and SMS stays in Concept.

When looking at this chart, everyone from management to development knows where we are now and where we’re heading (including where a feature is in process). It’s important those implementing and planning know where a feature or module might be heading (and why we did roadmaps to start with) so that they can build now with an eye toward the future. However, we didn’t have to put any arbitrary timeline on the features as a roadmap typically does. One final note: I encourage not only technical features to appear on the chart but also marketing, BD, content, and other related activities. This way, the whole organization can be mapped and coordinated in one place and in sync.

Kuroshio Sea - 2nd largest aquarium tank in the world

This is pretty amazing. Let it buffer first and then play it.

Kuroshio Sea - 2nd largest aquarium tank in the world - (song is Please don't go by Barcelona) from Jon Rawlinson on Vimeo.

Google Voice: New apps help but serious issues and carrier concerns remain

This post is in response to this TechCrunch article on Google Voice.

When Google re-launched GrandCentral as Google Voice it was a nice upgrade that included some new features and a more Google-like UI. However, there were still a few big drawbacks including: that you needed to adopt a new phone number, dialing to have your outbound number show up in caller ID as your GV number was clunky, and user/carrier issues with number ownership.

With the launch of these new apps, Google has taken a small first step toward helping with issue #2. However, this application is basically a hack that only covers a small subset of users who will have to change how they doing their calling and may run afoul of carrier calling plans. The way the application works is not by dialing your party but first dialing Google's number and then having that call forwarded to the other party substituting your number with your GV number. This special dialer app is only the default dialer on Google's Android platform but is a separate app on Blackberry and will be the same if they are able to deliver on other smartphone platforms. This means a notable change in how you dial calls which some users will balk at or simply forget to do and third party apps may not work with.

There have been rumors of Google supporting number portability where you could simply take your existing mobile number (or home #) and make that your Google Voice number. While this sounds like the right solution there are major issues for a user doing this: Google doesn't offer a full voice service so someone (presumably your existing mobile/landline provider) still has to provide you with service to take the call. If you switch your mobile number to Google, your mobile service will be shut off. Do you then have to sign up for new service on the carrier and possibly break your contract (same with landlines)? Not the hassle or expense the average user will go to.

The final issue with Google Voice is: when are the carriers going to thwart Google's efforts here? Clearly, GV is about customer and identity ownership. Google could have launched this service to be an overlay of your existing services and piggyback off your existing providers and numbers. However, that would not have them owning your identity (your phone number) like they do with your email address in GMail and thus less customer lock-in and less ability to target ads at you. In going with ownership of the customer and now creeping slowly but surely to disintermediate the carriers, the service providers are going to need to thwart this competitive threat. This threatens everything from Google pushing Android to the carriers to your calling plan. The last will be an interesting early battle front. With the way Google does their calling, you could simply put the special Google dialing number into your "Fav 5s" on T-Mobile and get completely free calling. Yes, Google will round-robin a series of numbers but this can easily be overcome. TMO won't let that happen. On the other side, if you have your spouse, mother, and best friend in your Fav 5s, using Google's new apps will now cost you money where they wouldn't before. That's because calling them goes from your phone to Google's number and then onto that party. To TMO, that call is to Google and thus outside your Fav 5s. All carriers have popular plans like this and this now makes them useless with Google Voice.

These are serious questions one has to ask before adopting Google Voice.

Agile PM: Concept Handling

Efficiently managing, vetting, and prioritizing new product ideas is one of the most important jobs of a product manager. A good PM not only collects and considers these but facilitates their flow. Ideas can come in from any or all of:

• Management: Are you are tapped into management discussions of high-level strategy and what their teams are seeing and hearing about your product?
• Sales/BD: Those on the front lines have a pulse on the market and often are a great untapped resource for what customers or partners are asking for. I’ve also found that salespeople feel their feedback goes unheard so ensuring that their input is being put into the product process is a good way to engender support and have them sell your product even harder (esp. important in larger organizations where salespeople are selling multiple products).
• Marketing: Sit in on marketing planning meetings so you get insight into what marketing plans are in the works. Marketing tends to operate in a vacuum and races ahead with a campaign and only ensures that the product matches the vision they are laying out at the 11^th hour.
• Competition: Are you tapped into information resources that are constantly reporting on your competitors’ offerings and what your customers are saying about them?
• Engineering: If you are building technology products, engineering is often one of your best resources for new ideas. By their nature, engineers don’t often speak of their discoveries outside their own team. Get yourself into their process so you can hear and see what they might have come upon.
• Customers and usage data: Are you directly interfacing, testing, and watching what your customers do with your product?
• Partners: Who are you trying to partner with and does your product support their efforts and technologies?

You cannot sit back and expect these to percolate to you. If you do, then it’s more likely that you only hear from the squeaky wheel (customer issues or management) then that great idea discovered in engineering or small but innovative partner with a great combo product idea that languishes without ever getting considered.

More rigid processes tend to struggle with “ideation”. They typically make coming up with new ideas part of a process where there are formal meetings to try and harvest ideas within the organization. There are a myriad of problems with this including trying to force ideas, timing, and inflexibility in considering any idea at any time. This last point is what Agile PM is about. A good concept should be able to be put in process at any time and considered for inclusion of the next iteration not just during formal product cycles. With hardware this can be more challenging, but with iterative software cycles this not only can be supported but really is a must. This way, innovative organizations can constantly adjust to the changing dynamics of their products and user/competitive landscapes. How many times have you heard a good idea be put aside due to it not being the right point in the product development cycle? I know I’ve heard “that’s a good idea but we’re really focused on getting v1.2 out this quarter” many times from PMs.

For a given idea, baseline information must be gathered. This includes a short summary of the customer and the problem its solving as well as a top-level user story. An example along the lines of our earlier case: “our small businesses want an easy way to publish updates about the company to their mobile sites since the sites are mostly static and require technical work to change them today. We could enable them to connect an existing RSS feed (or tell them how to create one) where we scale the content for mobile devices with alerts out to their customers for a fee.” This simple concept outline defines who it is for, the problem and the benefit, and a top-line description from which requirements can be generated.

After gathering the baseline idea and where it is coming from, it must be put into process to see if it has merit to prioritize and drive forward. The best way to do this is by gathering the leaders/stakeholders of the product (e.g. management, marketing, engineering, support, etc.) into a brainstorming meeting. Brainstorming means unstructured to many people. This really isn’t how the best results occur. A PM must bring a framework to brainstorming a given concept and fortunately we discussed and developed our product framework here. What we’re asking is: how well does this concept fit in with our overall business? Even if it does not seem to fit well at first, don’t shy away. Remember, as the PM, you are more the referee then the player in these meetings even if it is your idea. Try to be objective and take the feedback constructively. This will lead to a stronger product and more likely that the idea gets refined into something useful or dies on the vine as maybe it should have all along.

The brainstorming agenda should review the top level idea against the framework and then answer a series of questions for all those involved: do our users have this problem, will this get us new customers, is this feasible, what resources we have to shepherd to make this happen? The last two questions around feasibility also is one of the main decisions coming out of the brainstorm: should we prototype it? Prototyping takes resources and time but mitigates risk. Agile development is particularly good at this. It can be as simple as wire framing in the case of a visual for a website or writing a rough first pass of a key algorithm. Prototyping is not always the right choice but is often a good one. One rule of thumb: if those in the brainstorm can’t seem to agree on the relative importance and appropriateness of a feature, prototype it. Prototyping will also allow the development team to provide a more refined level of effort for the full implementation.

After you prototype (or if you chose not to), the key question is: what is the relative priority of this feature? Avoid simple numeric prioritization systems as the rankings are often arbitrary and not consistently understood amongst the team. I usually suggest something like: definitely, likely, and maybe. “Definitely” says that there is strong interest and belief that this aligns with our business and product goals. Don’t be afraid of “definitely” as there will be one more major filter, Drivers, to checkpoint whether this really is something to move forward. “Likely” means there’s a strong sentiment that it will become a feature but one reason or another doesn’t have us pursue it right now (e.g. lack of resources, related features aren’t yet robust enough, too far afield of current features, customer base is too immature, etc.). “Maybe” ideas are typically interesting but long-term concepts that should be noted but don’t require any immediate action. All of this then gets laid out on the Feature Chart (which is our next discussion). If your feature is a “definitely”, move it into Drivers.

Agile PM: The Process

Many people disdain process. Bigger companies tend to see it as a necessary evil to keep control over a sprawling product development organization. Small companies often eschew it as a symbol of big company bureaucracy which just enforces the tedious and inefficient bureaucracy. However, there is a happy medium in having a light-weight, flexible, and well-understood process in any product development organization.

Academically, I was rigorously trained in the waterfall model and worked in several organizations that utilized it (I still remember projects with two year development cycles for a first release!). I’ve seen the other extreme working with teams in Agile development and seen several formal and informal processes in-between. I’ve had the good fortune of working at a hardware company, Palm, who had a modern but rigorous process. In hardware product development, having more formal phases and checkpoints is necessary as moving from one to the other can cost large sums of real money and affect large numbers of internal and external resources. However, I also experienced the downside when this same process was applied to software product development.

The hardware process is setup so that cost, market and other factors have to be met to pass through a gateway. If you can’t find a way to manufacture device X at Y margin, you can’t keep pursuing it. Applying that to software didn’t work especially when software wasn’t our core business. The justification behind why we were doing a given software project might not be revenue driven at all. However, when your gateway process literally needs the CFO to sign-off on margin analysis, a peripheral software product that is a loss leader to drive customer loyalty isn’t going to score well.

From that experience and several others within large and small organizations I have developed this Agile PM Process. Some of the terminology should be familiar to those who’ve done software development as many aspects of the waterfall and other methodologies are good, but often misapplied with a one size fits all mentality. If you’re doing a bug fix and small feature release you don’t need a rigorous market study or customer definition. Process can be good for all.

All of these phases and sub-components will be discussed in future posts. However, let me briefly describe the purpose of each, how they differ from other approaches, and how it better matches with and integrates Agile development.

• Concept: This phase always exists (less you’d be without any new product ideas) but often is rapid and informal in small organizations or overly bureaucratic in large ones trying to force new ideas (often termed “ideation”). The concept phase takes an idea that could have come from any of sales/BD initiatives, user feedback, management direction, engineering discoveries, etc. As the product manager, you are setup to facilitate ideas from all these sources and put them into process. For a given idea, it needs to be tested against the product framework (we already discussed) which the management team has hopefully developed. Some degree of brainstorming – with the key constituencies who might be responsible for developing it (including engineering) – needs to occur. The team should recommend whether or not it should be prototyped (e.g. wire frames in the web/UX world, rough implementation, mock-up, etc.) to increase understanding and reduce risk. From that, a checkpoint decision is made as to whether it merits moving to the next phase and its placed appropriately on the feature chart (to be discussed).
• Drivers: If an idea is interesting and relevant enough, it enters the Drivers phase to determine if it has the business case to merit moving forward. This is where much discretion has to apply by the product manager as to the degree of support the idea needs to increase understanding and reduce risk. If it’s a major new product initiative the risk should be reduced by being more rigorous. If it’s a small feature update then it can be streamlined. However, a customer and their problem should always be defined and it always needs to be set against the Risk & Prioritization matrix (to be discussed) to move it forward.
• Specification: So we’ve decided we’re going to put a feature idea into production. We know why we’re doing it and for whom. Now we need to set the specific requirements and apply the appropriate level of design to hand to the development team. Of note, the development team is heavily involved here and formal specification is mostly avoided so that they may rapidly iterate with feedback during Development. It’s perfectly appropriate and even empowering to have the design and development team be one in the same.
• Development: We know what we’re doing so let’s iterate, Agile style. The product team needs to be looped back in to give feedback on each iteration and ensure it’s on the right path. Test, test, and test again.
• Maintenance: The most overlooked of all phases but your product management does not end with delivery. You should have laid out success metrics as part of your business case and now you have to measure them. There will always need to be fixes and enhancements. How are those balanced with new initiatives? Does this product have a logical end-of-life? We have to plan for that and transition of users and/or data.

Some of this might seem traditional and daunting but it tries to balance the necessary and beneficial parts of process with the flexibility request by and afforded to those engaged in Agile development.

Terminology and Click-Throughs

An interesting (albeit non-scientific) study on how language affects click-throughs. The author's conclusion: personalizing it by saying "You", giving a command, and adding "here" increased click-throughs significantly. The resulting phrase "You should follow me on twitter by clicking here" increased click-throughs by 173% vs. "I'm on twitter".

I think there are confounding effects that invalidate this statistics-wise. First, simply adding more words raised the visibility of the statement. Second, there didn't seem to be much of a control for the study group so there could be other effects simply based on the volume and type of traffic (did he get pick-up on another blog thus driving many new readers vs. existing ones for a given post when he had the higher click-through phrase).

However, I think there are a few nuggets to understand here:

1. Marketing-psychology studies have shown that personalizing something and talking "to" people vs. "at" people (a personal pet-peeve of mine) increases effectiveness. It makes people listen as they feel they are being directly addressed and they tend to internalize and empathize with what you're saying.
2. Using a clear command call to action drives people to act. Its not rocket science but people often forget this.

You should read the full article here ; )

Agile PM: Product Framework

To be successful as a product manager (or “owner” as I advocated in the last post) you need a context under which you are developing your product. A product should not be conceived, designed, and developed in a vacuum. You need to frame the product within the business goals, product pillars, and customer definition of the organization you are delivering this for. I call this the Product Framework.

The framework is the context within which you develop your product. It provides high level drivers to match product features against as well as a structure to prioritize, defer, and report features. Let’s discuss each area briefly (future posts will discuss many of them in-depth):

• Mission and Vision: The overall mission for the company. Many early stage companies skip over defining a clear mission and I think they suffer because of it. Startups often lack focus, suffer from a disconnect between what’s in a founders head and what employees think they are working on, and are tempted by many peripheral opportunities. A mission statement can help with many of these issues. An example: We improve customer opportunities for small businesses by enabling them to have a presence on mobile devices for marketing and transactional purposes without any setup or technical administration.
• Business Goals: Specific top-level business goals that can be measured and quantified to some degree. These should be set by the board and management for the company and updated regularly as conditions change. They could be growth (achieve X% market share by Y) and revenue (drive $X per quarter) or even more specific like releases (beta release by fall), features, or organizational (hiring or cost efficiencies). These are important because the life and goals of a product are directly taken from them. If you know that your first release must be out soon and its goals are to drive user-acquisition vs. revenue, you can focus and prioritize your feature set.
• Product Pillars: Three to five fundamental assertions that back the business thesis. Examples are easier here: 1) The long-tail of small businesses are under-represented in the mobile revolution and face being disenfranchised as more people rely on their devices for local information; 2) Creating a mobile presence is unachievable for most SMB given cost and complexity; 3) Having a mobile presence provides an opportunity for marketing, transactions, and customer loyalty programs not traditionally achievable for SMBs.
• Customer Definition and Problem: Who is our specific customer (or customers) and what is their problem we are solving. This is one of the easiest but frequently overlooked tasks. It doesn’t need to be a detailed customer profile but a simple customer->problem->solution statement. If you are not fulfilling a need that exists today you probably are a “cool” technology looking for your problem. To continue our example: small retail and service businesses do not have the resources or technical acumen to build a presence and infrastructure on mobile devices and face being left out of customer awareness and loyalty as more people depend on their devices for local information. We provide that at a price-point they can afford.
• Product-Specific Goals: What are the goals for my specific product (or sub-product) relating to the overall business mission and goals? These should be closely aligned and might be one-in-the-same, but it’s good to lay out a set of more specific goals for what you’re working on now (this particular product iteration). Example: A quick, simple, and free UX for SMBs to setup a storefront first focused on marketing/awareness where we do the online/mobile marketing for driving customers to them; next we’ll focus on facilitating customer loyalty programs for the customers they attract; and finally act as a transactional marketplace so they can provide couponing and on-device transactions both in-store and out.
• Priority Features, Deferred Features, and Release Roadmap: Now that you know what you’re doing, how do you prioritize features and put a plan together. We’ll cover this in a lot more detail in upcoming posts.

The interesting thing I find in many organizations, large and small, is that many of the elements of the product framework already exist. However, it often isn’t formalized in a concise way that all agree on. Even if senior management has discussed this, it isn’t well communicated throughout the organization. It can be challenging to complete, but I’d assert that if you don’t know and communicate this throughout your organization you increase your failure risk factor and inherit inefficiencies that most organizations don’t want.

Agile PM: Core Responsibilities

Before we get into detail about the agile product management process, let’s establish what I believe are product management’s core responsibilities. There are obviously variations given the product and organization but these are hopefully generalized enough to apply to most technology products and services (they always have for me).

1. Provide detailed research and rationale for a product plan that implements business goals
2. Take all inputs (vision, management, marketing/sales, user feedback, engineering, partners, etc.) and prioritize into an executable plan
3. Provide direction for project team to adapt when implementation hurdles arise
4. Create tools and metrics to monitor and measure product success in meeting goals
5. Provide a plan (often a “roadmap”) for internal and external parties to manage the business

One thing I encourage all the organizations I work with to do is make each product manager feel and act as the owner of their product. The degree to which this can be done varies and is impacted by the seniority and skill set of the PM team. However, if a manager feels that their PM team isn’t senior enough to be the complete “owner” of a large product, they should break down the product into component parts and make the more junior staff sub-owners of those while retaining overall ownership themselves.

The product management function is placed in quite a few different parts of organizations. It often is close or falls under the auspices of marketing. Other times it’s close to the development team and occasionally intertwined with “project” or “program” management. This is not a good choice. Managing a project – ensuring that a given set of tasks toward a goal are completed on time and within budget – is not only a different skill set, it is often at odds with product management. An example: as is inevitable on most technology developments, getting the desired features delivered on the original schedule is challenging. A project manager deals with the day-to-day of trying to stay on schedule when moving parts (mostly design and development personnel) influence plan. However, when a point is hit where something has to give (feature or schedule) there need to be at least two voices: the project manager who can speak to resources, tasks, and schedules (generally: availability or scarcity) and the product manager who speaks to which features (and degree of implementation) should be prioritized. This is a key negotiation in most organizations and is essential to keep both sides in check and focused on their constituencies.

I advocate a separate product management function in almost every organization I advise, reporting into senior management. This is so that there is a voice of the user and the business. When the function sits under marketing it can often be pulled too close to tactical marketing efforts and away from the user and business goals. Someone must sit in the middle and balance the sales and marketing programs while interfacing with the project team in development as well as be answerable to senior management in how the product is meeting business goals.

Agile PM: Objective Criteria to Focus on Priorities

A key difference with this agile product management approach is that it focuses on something which most other processes avoid (or do informally): an objective way to rationalize and prioritize features. Most formal product management focuses on the formal elements that define a product/feature: MRD, PRD, Spec, Design, etc. During the flow from concept to delivery there are checkpoints where management sign-off happens. In those meetings, there is often some discussion of priority. However, it’s usually at the whim of whomever the feature is a priority for. If that is not a person empowered to make a decision it’s often put on the backburner. If it’s a senior manager it can often be prioritized without justification. In smaller companies, individuals often drive priority based on whoever is providing the vision. In a startup, that’s often the founder(s) and can lead to conflict when done in a vacuum without justification or clear communication to the other team members.

In contrast, having objective prioritization and ranking criteria as the centerpiece of the process puts an emphasis on how what we’re doing matches with our goals. It relieves pressures from “cool” features or other whims that might overly emphasize something. It not only facilitates a critical piece that is difficult for other processes, it allows for any team member to challenge a given feature/product’s importance. If a feature doesn’t match your business priorities it’s difficult for anyone (even senior management) to justify it unless your priorities are off which is a bigger problem.

It also better matches with agile development. Agile forgoes most formal documentation and emphasizes user stories (mostly high-level use-cases) and then iterating quickly with a feedback mechanism to refine the requirements and resultant feature. Since requirements are done more informally and rapidly with a built in iterative cycle, the checkpoints can be more about priority and less whether the feature and design is correct. If you agree something is a priority against your objectives then you can christen a prototype or the first iteration. If, after the review of that iteration, it doesn’t match objectives then it can be de-prioritized and little was lost beyond the limited resources used on that iteration. In a traditional model, you’d have to start the process all over again and review and redo the “roadmap”.

I’ve seen substantive results with this process. I’ve implemented it in organizations I’ve run and have been brought in as a consultant to deploy it for teams that were struggling with product management. This is often in smaller companies (or teams within larger organizations) when they are going through a classic transition phase (e.g. from founding team to funding and 10+ employees; after initial product development and 15-20 employees needing to formalize to scale the business and thus product effort). One size doesn’t fit all and the nature of the specific business the company is in, the skill sets of the team, and dynamics of management mean that this basic framework and its principles are customized to meet their needs. And to use one of my own basic principles: to be flexible and adapt during the process, I’m always tweaking it and (hopefully) improving it from feedback. Input is always welcome.

An Agile Product Management (intro)

Over the coming weeks I’ll be posting musings on modern technology product management. Over the course of my career, I’ve played a variety of roles in developing technology products and services. This ranged from being an engineer on multi-year, 20+ person complex trading systems to running engineering teams to being the GM of cross-functional mobile product teams to leading new product startups. Through these experiences I’ve participated in a myriad of methodologies, both formal and informal, to deliver on the projects. As I’ve been in more of a leadership role over the delivery of products, I’ve begun to morph the various methodologies adding my own elements and stripping out what was overly bureaucratic or inefficient.

In concert with this has been the advent of agile development techniques adopted by engineers mostly from the open source community and organizations with engineering driven cultures. Coming from a technical background, I have an appreciation for what the agile techniques attempt to change about the traditional waterfall models. However, this empowerment of the engineering process has also shined a brighter light on the often large gap between the business/product owners and those implementing it. Agile adapted to be more effective for engineers attempting to deliver the right product in the defined scope but the people and processes around them have not adapted.

These discussions will lay out a new approach to technology product management which takes many cues from the principles of agile as well as the needs of the business driving it. It recognizes the new power sharing arrangement that is often in play (be it acknowledged or not) between the product team and development and is flexible to adapt to organizations both large and small as well as to each idea that arises. Most processes are one size fits all which often leads to their ineffectiveness and people trying to work around them to avoid the daunting tasks involved. In putting an onus on product ownership and individual accountability, this “Agile Product Management” allows the day-to-day management to be pushed down and objective oversight to come at key gateways with some new reporting tools. It also empowers anyone in the organization to question the rationale behind a product feature since it proposes a set of objective criteria for evaluating their priority and value for the business.

Talk2Us has launched! Want to see the next generation of communications? Try our private beta at: http://ping.fm/guXZ3

celebrating Tabs' second birthday

In silicon valley for a day of meetings and then on the redeye home (fun)

In SF for wedding and remembering my love/hate relationship with this place...don't miss the travel

The pitch went well...now let the checks start rolling in ;)

Preparing for the Talk2Us 10 minute pitch in front of 100+ investors tomorrow. Going with a refined and simplified angle. Hopefully, funding follows thereafter.

I am trying out Ping

CTIA

I'm down in the Big Easy at CTIA (Cellular Telecommunications Industry Association) show as part of my day job. CTIA has gone from a side show for the guys that build cell towers to the main mobile industry event. I have a lot of activities with each of the big US carriers. I also be walking the floor looking at interesting new mobile apps and services (that is my job after all). I'll write up some thoughts on what I see.

Some have also asked me my perspective on the mobile industry which I'll start posting about here in the future. Much going on and one of the few tech places that has some real momentum these days. However, this industry functions a lot differently then other traditional sectors of tech.

Digital Concierge

WSJ Small Biz today has an article about yet another attempt at a digital concierge service. As the article points out there have been many attempts at this from small companies and large (I even advised a startup several years back that was doing this and I never saw the business case -- they later folded).

This firm, Rearden Commerce Inc., is focusing on doing this for corporate customers. The one thing I like about their approach (besides the fact of focusing on the B2B vs. the consumer market) is that they are basically an aggregator of common (and expensive) corporate services such as shipping, travel, etc. Their first few areas are the low hanging fruit of this business but stretching it to a real concierge service is quite a bit of a leap. Companies have been outsourcing these types of things for some time and as Intranet portals actually become a useful reality these services can tie in nicely.

I doubt though that this can become a huge independent business. One major problem is that they could suffer from the "jack of all, master of none" scenario since all their services are offered independently elsewhere. Or, will corporations see the benefit of one stop shopping and scale? Not known but a minor interesting point on the biz scale.

WOXY

While not directly on a biz topic I'd like to suggest everyone go to woxy.com as it's a great modern rock radio station. Playing a lot of the best new stuff from current bands and a solid blend of classics. It's probably the best radio station I've ever heard and they are often sited as the top station in the country. They're independent and have little advertising so they aren't catering to any tastes other then good music. The DJs are solid music geeks.

Actually, there is a biz side here as this station was a classic broadcast station based in Cincinnati who decided to go internet only a few years back. Now I'm no expert in the radio biz other then the obvious it is interesting to see this happen. One positive effect (besides the fact that I can sit in NYC and listen to them) of doing this is that they get an int'l audience who not only send in a diverse set of requests but also recommend new bands.

In any case, I think they run on a shoestring so hopefully they'll keep going. Listen and support as it has renewed my faith that there is good music still being created since you don't hear it on the corporate owned radio or on MTV/VH1 (VH1 classic isn't bad though). And guess what music industry, I've bought 10 CDs of bands I heard on there and after I was able to download a few MP3s off their website.

Microsoft buying Groove

Not shocking but certainly of note is the announcement today that MS is buying Groove. A quote from the WSJ article:

"Microsoft Corp. said it will acquire Groove Networks Inc., a closely held maker of office collaboration software, for an undisclosed amount. Groove, based in Beverly, Mass., makes "virtual office" software that allows groups of workers both in and outside companies to share files on their personal computers and to work on them simultaneously. Groove's peer-to-peer networking concept is similar to Napster's original music-sharing system. Groove was founded in 1997 by Ray Ozzie, the creator of the Lotus Notes e-mail software. Once the acquisition is completed, Mr. Ozzie will join Microsoft as its chief technical officer, reporting to Chairman and Chief Software Architect Bill Gates."

I know Groove fairly well and this area of technology is near and dear to my heart as I've worked on similar things at several points in my career. I became aware of Groove several years back when I was advising a startup working on similar software. Groove was the high profile entrant in the space at the time esp. after receiving a large investment from MS.

It was pretty inevitable that MS was going to put these types of collaborative offering into Windows (Longhorn or beyond) so I'm sure the Groove offer was typical MS: either you are subsumed and become that for us or we kill you. Similar to the many other deals infamous in MS history. Groove's product is not bad but a bit underwhelming for what collaboration needs to be. I'll save space here for a diatribe on that but suffice to say that the technology will fit in well with MS being the lowest common denominator type of collaboration.

The most interesting aspect of this deal is Ray Ozzie (founder of Groove and inventor of Lotus Notes) who has spent much of his career in an anti-MS capacity (including some famous quotes in the old days of Notes-Exchange wars). Having him as CTO working with Gates is funny esp. as Gates said in his CNBC interview how he's been trying to hire Ray for years. Given the 800 lb gorilla that is MS I somehow doubt Ray will have a tremendous influence on future direction but he is a strong personality.

Small biz accounts for 99.7% of US employment?

In an article today on the WSJ small business site I was astonished at this quote:

"The nation's 23.7 million small companies account for 99.7% of U.S. employers and pay roughly 44% of the country's private payroll, according to the U.S. Small Business Administration."

Now, I always knew small business accounted for a lot (even a majority) of employment in the US but this seems puzzling. As usual with stats it seems what you assume and how you spin it is important here. First is the definition of "small business" which I've always used $10MM or less in annual revenue. Some people also use employee stats of less then 100 or 500 in some cases.

Even with that, it's still hard to believe it could be this high esp. given that the federal, state, and local gov'ts employ so many people. Or, those might have been excluded. In any case, interesting to know...and use creatively in your b-plan if it suits you ;)

Making money with blogs

Speaking of blogs and business, here's a good article on making money with blogs. Not rocket science but interesting to see that if you actually produce some decent content and create a following you can make some supplementary income with ads. No ads coming here as of yet...

Is there a decent blog software out there

So here's a concept for my first real post: how about someone write some decent blogging software! In looking for a place to host this blog I tried out quite a few services. They all had major problems. Some just didn't have many features, some had nasty UIs, and others (like blogger.com) had major stability/bug issues.

Well, I am sticking with blogger for the time being simply because it offered all the features I wanted for free and has a decent UI. Now, if it only worked at least 80%+ of the time we'd have a real winner. Oh well, I guess Google can't hit a home run every time.

Getting Going

Well I'm getting going trying out this whole crazy "blogging" thing. Ironic since I was involved in the early days of online chatting, communities, and information sharing. I'm doing this for a few reasons:

1) To keep a decent log of more interesting biz and other information I find on a daily basis
2) To discuss with friends et al ideas and concepts with my interest in entrepreneurial ventures
3) Just to be as cool as the other blogger-kids

Feel free to point others here. It's not a closed community.

Here's the RSS feed if you'd like to plug this into your favorite news reader:

http://ajbbiz.blogspot.com/atom.xml