One of the face palm moments I had while researching PM's role in SaaS was the timeline for platform and app development. The traditional path for on-premise products was platform first, then application. The cloud products flip this sequence, putting the applications first, then the platform. We're so used to seeing this pattern that it's easy to take it for granted, or mistake the reasons why it exists (hence the face palm).

There were two reasons for this evolution in the natural history of a tech vendor's portfolio. The first is distance from the customer. In an on-premise world, where there's a lot of geographic and organizational distance between the producers and consumers of technology, the collection mechanisms about customer adoption (infrequent "How ya doin'?" conference calls, cryptic bug reports, etc.) are labor-intensive. For however much effort you put into this research, the information returned is often incomplete, distorted, or just plain wrong. For example, the game of Telephone played among product teams, customers, and the salespeople in between often leaves PMs with more questions than answers about what a customer really wants. 

Therefore, the product strategy for on-premise products have to accommodate a lot of uncertainty about how customers use the technology. While it's not the only reason for customization and custom application development, it's certainly an important one. Rather than guess wrong about customer adoption, on-premise vendors tend to say, "Here's a toolkit. Go build what you want."

On December 5^th, Verizon Wireless launched its Long Term Evolution (LTE) network in 38 cities and in over 60 airports. This deployment signals the beginning of the 4G/LTE wars. The fuss over 4G/LTE networks is based on significantly faster network speeds which enable a smoother, faster, less jittery video experience for customers. Verizon’s LTE network is expected to run nearly 10 times faster than the company’s 3G EVDO network with downstream speeds of 5 Mbps to 12 Mbps and upstream speeds of 2Mbps to 5Mbps.

 Initially, Verizon Wireless is taking a land grab approach to marketing its LTE network service primarily to business customers who can connect to the Internet using their laptops. Data plans start at $50 per month for 5GB of data, or $80 per month for 10B of data. Additional data use above these data plan caps will cost $10 per GB. Lower price point plans which would appeal to cost conscious consumers were not identified. Verizon plans to offer LTE enabled smartphones in mid 2011.

The $50 per month baseline LTE data pricing plan is undercutting Verizon’s current 3G data access prices. Why undercut 3G data prices? Because the 4G/LTE competitive landscape is heating up. Clearwire is deploying a WiMax network in 68 markets, and T-Mobile is positioning its HSPA+ network as 4G in more than 80 markets. In addition, Verizon is hoping to capture a significant share of customers in the 4G market before AT&T jumps into the 4G arena in 2011, so expect more 4G/LTE announcements and increased competition for 4G customers in the coming year.

Scott Sehlhorst has an outstanding post at Tyner Blaine about documentation. Not technical documentation, but the information you write down to make the development process work. By work, I don't mean just the activities within the development team, but also the rest of the value chain, too.

Scott is talking about the role of documentation in Agile development, but his points are relevant to any team, Agile or not. Agile creates greater sensitivity to the issue, since too much documentation can cripple the team's velocity. Of course, the lack of documentation can damage the team's success:

Some collaboration is transient – communication happens right now, and is only important right now.  Other communications are persistent – the collaboration happens right now, but we need to remember later what we agreed upon and why.

Scott's post is a great illustration of what I was discussing yesterday about treating requirements as conversations, not dictionaries. Requirements are part of the conversation, but a lot of the same content that defines what to build, and why, gets recycled later when you need to describe what you built, and why. For example, personas get passed around quite a bit among groups. Perhaps the originate in the development team, but people in sales, marketing, support, and other downstream groups have a keen interest in that information.