I have been a Zune user dating back to the First-Generation devices. While the color choices for the outer casing were a bit suspect (I owned the “PBZ” color, with “PBZ” affectionately meaning “Poopie Brown Zune”). I wife and kids were (and still are) regular users of the smaller 4 and 8 GB Zunes (Second-Generation with solid state drives). I still carry a Zune HD, which in my opinion was the hardware for a personal media player – period. Now, I’ve used other devices over the years, including even after the Zune came out, but I always returned to the Zune platform. Part of my reasoning for going back was around the software and ecosystem (the best device UI and Zune Pass are two examples), but another part of it was around the hardware itself.

I think the Zune serves as a great reminder of how Microsoft markets so many of their products and how unsuccessful the strategy ends up being. Microsoft often times tends to spend a lot of time, effort and money building up interest and “hype” for product. Many times, this does work. However, once a product launch occurs, the effort goes from “great” to “virtually non-existent”. The history of the Zune may may the greatest example of this strategy.

For each generation of Zune, Microsoft put forth a lot of effort in marketing “what’s coming”. While some can argue the effectiveness of this marketing (personally, some of the “hip and trendy” ads reminded me of an old stodgy person’s impression of “hip and trendy”, the amount of exposure given was not in question. Once each generation of Zune actually launched, however, Microsoft seemed to disappear from the scene when it came to marketing. I don’t claim to know or even understand Microsoft rationale behind this, but it almost always seemed to me that Microsoft assumed -

1. People got the message, and no further marketing was really necessary;
2. The ecosystem (retailers, in this case) would pick up the marketing slack and sell for them.
3. Enough money was spent in preparation for launch, and spending more just wasn’t prudent.
4. All of the above.

I tend to ascribe in some form to the “All of the above” theory, but again – I’m not that much in-the-know. Whatever the case may be, Zune always seemed to fall into the “what’s that” category from a consumer awareness perspective.

I have lost count of how many times over the years that I showed people my Zune hardware, mainly because the people wanting to see it had little to no idea such hardware and software existed. Usually (and especially when it came to the Zune HD), folks were really impressed with the Zune experience. In almost all cases, though, people would take the stance of “Nice, but it isn’t an iPod.” Drill down with people on this stance and almost always this really meant “I don’t know enough about this Zune thing, but I know LOTS about an iPod”. In essence, Microsoft’s assumption that pre-launch marketing was enough simply fell flat on it’s face. Zune constantly suffered from a lack of brand recognition. 

The good news (if there is any here) is at least aspects of the Zune experience outside of the hardware itself are living on strongly in other Microsoft products. The Zune music services live on in Windows Phone, desktop and Xbox 360. Almost as importantly, the Zune user experience lives on and thrives throughout Microsoft products. Most people forget or are unaware that the roots of the “Metro” user interface now appearing in Windows Phone 7, Xbox and even the upcoming Windows 8 operating system were born from the Zune user interface (I distinctly recall so many people calling Windows Phone 7 the “Zune Phone” when the first images of the user interface went public). All of this good news, however, makes me wonder even more how a platform generally can gain so much acceptance and acclaim, yet the hardware that started it all could struggle for so long and eventually die out without so much as a bang but a whimper.

Hopefully, Microsoft will learn from the life and death of the Zune as a device. Sadly, many of the same issues around marketing strategy dogged the old Windows Mobile platform and (sadly) seem to be repeated to some extent with the newer Windows Phone 7 platform. Maybe, just maybe, Microsoft will eventually learn that the “if you build it, they will come” approach to product marketing isn’t always enough, and brand recognition is a 24/7/365 marketing effort.

Now, I will stop writing and go back to listening to some music on my Zune HD (suddenly a collector’s item)…

This type of conspicuous consumption has fueled economies since, well, forever. Of course, in uncertain economic times (like the present) we as consumers usually take pause and finally do ask ourselves if technology purchases are really serving a direct benefit and addressing a real problem we currently have. Ironically, however, another form of consumer (not the individual one like you or I) exists that suffers from some of the same impulse-buying and lack of forethought that we do. Their purchases, on the other hand, often run into the tens (if not hundreds) of thousands of dollars. And the people making those purchases are often themselves paid well to behave in just the opposite fashion of their spending habits. The consumers I am referring to are businesses.

As someone who has spent nearly a quarter of a century working with businesses and their technologies, I still find myself amazed by the number of times organizations acquire technologies with little to no idea of how they are going to actually use them. They spend large amounts of money investing in technologies, only look at them post-purchase and collectively say “now what?” While the technologies have changed and evolved over time, the acquisition of technology still occurs and results in a solution struggling to find a problem. Here are two such technologies I see this occurring with quite regularly lately, with one hitting very close to home on a personal level.

• Cloud-based solutions. Everything seems to be moving to “The Cloud” lately. Centralized, externally-hosted solutions are intended to generally solve very specific problems, such as:
  • Reducing the cost of infrastructure. Less hardware and/or software to maintain, less network bandwidth and reduced licensing.
  • Reduce the cost of operations. Less human resources needed to maintain infrastructure.
  • Ease access to corporate data and applications.

  However, I am amazed by how many people currently consider moving to cloud-based solutions that currently are not experiencing these problems or will not see these problems occurring any time in the future. In fact, in these cases the cost of migrating from in-house to the cloud will likely cost significantly more in both the short- and long-term.

• Device Management solutions. This is the one I said hits close to home for me, working in the industry directly. Typically, device management platforms today can help to solve a number of issues around mobile devices and –
  • Asset tracking and reporting;
  • Security configuration and enforcement;
  • Application management;
  • Identification and control over both corporate-issued devices and personal devices accessing corporate resources.

  Here again, however, I regularly meet with organizations “post-purchase” of device management solutions only to discover that they really don’t know what problem (if any) they are trying to solve.  In many cases, there is really no strategic direction/planning around mobile devices. In all of these cases, questions directed at the customer regarding what they hope to leverage from device management are met with responses like “we have no idea; what do you think?”

Technology is an enabler; it helps us to do things more effectively, or at a lower cost. Technology is not an automatic solution, however. In order for it to solve a problem, there has to be a problem in place and the technology needs to be looked at to validate whether or not it is, in fact, the solution. Whether it is a new dryer or a device management platform, the same principles apply.

Well, a couple of interesting thoughts occurred to me during this particular platform fragmentation discussion. First, I found someone in the discussion tried to make an argument that just didn’t fit in defense of the particular platform in question (in this discussion, it was Windows Phone 7.5). The argument was, in essence, that “platform fragmentation” only occurs if the platform causes a given application to work on one device and not the other. I found this argument to be the equivalent of something like changing the dimensions of a soccer field in the middle of a game and then calling everything that was inbounds before suddenly out-of-bounds. It just doesn’t work that way.

From my perspective, I look at a platform from a very gestalt point of view. In other words, the whole of the platform is greater than the sum of its parts. This includes all aspects of the platform. In the mobile world, this includes any OEM relationships, mobile carrier relationships and the ability of the platform (in this discussion, it was the Windows Phone 7.5 OS as a major factor in the overall platform discussion) to allow for customization by the other players in the ecosystem. Remember – unlike Apple with iOS as a platform, there is literally no other “players in the game”; their manufacturing partners have specifications dictated to them, and mobile carriers have no ability to customize other than adding software (and only with Apple’s blessing). Now, with all this in mind, it occurred on me that there can be good aspects to platform fragmentation. The first example came out of the very discussion where someone was trying to change the parameters around what defines platform fragmentation.

A platform that allows for device manufacturers to differentiate through hardware capabilities opens the door for platform fragmentation. However, that type of fragmentation enables:

• Differing screen qualities
• Differing audio qualities
• Integration with other technologies (take DLNA, for example, allowing for streaming from the phone to other devices)

Now, if this particular form of platform fragmentation is allowed without altering the fundamental user experience (something I will touch upon in a moment), then it becomes a “win-win” for both devices manufacturers and consumers. Device manufacturers can compete through hardware and feature capabilities, while consumers have more choice without fear of a differentiator altering expected functionality. The end result – a positive type of platform fragmentation.

From a “bad” point of view, there are in my opinion several major types of platform fragmentation. They include -

• Allowing for functional changes that break consistent user experiences. The scenario that was positive above becomes negative if a device manufacturer adds or removes capabilities that make application no longer function or change the way users have to perform basic tasks (turning on WiFi, for example). When this happens, moving from device to device within the platform makes for a painful new learning curve and removes the expectation of basic functionality.
• Allowing for a device manufacturer or carrier to alter the basic user interface experience. Think “skinning” or “theming” here. While there can be an argument (both for and against) allowing users to change the fundamental appearance of the user interface, allowing devices to be sold with this as a default leads to a number of issues, including:
• Altering the fundamental expectation of user experience;
• Creating confusion through a lack of recognition of a platform. This was often the case with the old Windows Mobile platform and now occurs quite often with Android devices. Users do not even recognize and cannot identify what platform the device is running, never mind easily perform common tasks. Again, user frustration and new learning curves result when moving from device to device within the platform;
• Difficulty for the consumer in determining what device is best for them within a platform. The number of returns of devices because of issues like the ones listed above lead to dissatisfied consumers.
• Creating splits within the platform to accommodate hardware and features. Anyone remember the confusion caused by Windows Mobile Standard (non-touchscreen) vs. Windows Mobile Professional (touchscreen)? How about Android Honeycomb/3.x (tablet-specific) vs. the Android 2.x variants (tablet and non-tablet)? These splits result in software compatibility issues and even greater confusion/frustration for the consumer.

I guess the points I am trying to make here are, quite simply:

• Platform fragmentation almost always will occur to some level with technology, especially when the technology includes an ecosystem with more than one vested interest.
• There can be good forms of platform fragmentation that allow for grater choice for consumers without confusing, frustrating or hurting them.

To argue the basic definition of platform fragmentation shouldn’t be the approach when it occurs. Instead, the argument should focus on the benefit or detriment of the fragmentation in question. 

So – what coming? Well, more of what I have done in the past. Thoughts on technology, observations and (of course) the occasional rant.

Stay tuned…

If you read my introductory paragraph closely, you may have noticed my careful choice of the phrases “proposed standards” and “world of promise” when talking about HTML 5. There is a reason for that – HTML 5 is not yet an official standard. In fact, the W3C (the official sanctioning body for HTML specifications) has recently mentioned that final ratification may still be years away. I totally understand and accept that fact. I also understand, however, the potential implications that presents for today and until the time that a final specification is ratified.

My web development as a professional consultant actually goes back to the days when HTML 2 was a proposed standard (ah yes… when a company’s web site was largely static and, well, rather plain or ugly by today’s standards). As HTML evolved, from proposed specification through the ratification process, the following events have ALWAYS occurred:

• Company A that supports using HTML (read – “browser maker” or “web development tools maker”) implements their “interpretation” of the proposed HTML standard in product.
• Company B that supports using HTML decides Company A’s interpretation isn’t quite right and implements their own variation of the proposed standard.
• Companies C, D, E, etc all do the same.

Back in the days of HTML 2 and HTML 3, we were fortunate in how limited the number of “companies” referenced above were. Even then, however, the differing interpretations often created such development havoc that building one application for the web was more time- and resource-consuming than building separate native applications. Anyone reading this remember HTML 3 or 3.2 and the “Internet Explorer/Netscape Navigator Browser Wars”? I sure do. The varying approaches that Microsoft and Netscape took towards “implementing” HTML specifications soured many businesses from moving to the web. In fact (and totally in my opinion), I believe that the fallout from the “Browser Wars” actually set back web adoption by a few years. Unfortunately, HTML 5 is setting up to walk down this same path again.

The “HTML landscape” of 2011 is far more complex than it was a decade-plus ago. The number of “companies” (those providing fundamental support for HTML through browsers and development platforms) dwarfs the numbers of the late 1990’s. Furthermore, their stakes in the HTML market are far greater and extend far further than they did 10 years ago, with the desktop and mobile web reaching a vastly larger audience. During this “Wild West” period of HTML 5 implementation, when there is no final specification and plenty of room for “interpretation”, these companies have the ability to lead developers down a single path that could, in turn, restrict wider use. While there is no guarantee that this will happen, history speaks otherwise. This risk, in turn, is one that potentially result in a repeat of the development nightmares of the past. Even as we speak, current browsers and their “HTML 5 support” are beginning to cause developers to spend extra development time and effort to ensure that what works for “Browser A” also works for “Browser B” (and “Browser C", D,E and F”). Speaking strictly from a risk management perspective, the longer the time it takes for formal ratification, the greater the risks become.

While I eagerly await the day when HTML 5 is formally ratified and HTML 5-supported platforms come into greater alignment, I have a hard time staking my (or a company’s) development investment on the standard. While the HTML 5 “companies” continue to bombard me with messages on why I should invest in their HTML 5 implementations, I cannot help but feel that their answers to HTML 5 will lead me to a point where I will be either sandboxed into just their products or be forced to spend a lot of time coding my way out of their sandbox. All of that leads to that familiar sinking feeling of the past. That feeling is something I already have faced one too many times. So, I will stick with either native mobile applications or web applications that work across platforms (complete with limitations) until I feel comfortable that the sinking feeling will stay away.

Lower your standards.

While this quote does make me giggle, reminding me of an old Jon Lovitz sketch on Saturday Night Live years back, the statement does have some truth to it. You see, I believe that for many employers beginning the foray into mobile applications, hiring one developer will easily fill the need. Before you go any further, there are some things you should be aware of in order to avoid some disappointment as your hiring search begins.

• There is more than one mobile application platform out in the world. I find far too many recruiters looking for a mobile developer who, when asked to define which mobile platform will applications be developed for, simply respond “I don’t know” or “does it matter”. The simple answer – “it makes all the difference in the world”. Today, there are several major target platforms your company could target for development – iOS (iPhone, iPad, iPod), Android, Blackberry, Windows Phone. There is not a “one skillset fits all” solution to this situation. The tools, languages and techniques used to fit the development needs all vary (more on this below). As an employer, you should take the time to really refine which platforms you desire for your applications. If you don’t know, perhaps you should first take the time to research your real needs.
• Each mobile platform requires different technical knowledge. While many concepts around mobile application development are common to all platforms, the actual implementation/development skills around the platforms vary to a significant degree. iOS development requires knowledge of the Objective-C programming language. Android and Blackberry, while both leveraging Java as a language, use differing extensions of the base language. Windows Mobile and Windows Phone both leverage .NET languages (C# and VB.NET), but with significant differences from their desktop and web siblings. The assumption that one developer will be fluent in all languages is a precursor to disappointment.
  To see just how rare the multi-language skillset is for developers, you probably would have to look no further than your current in-house IT group. Just ask any in-house developer how difficult it would be to move an existing desktop application from .NET to Java, or a web application from PHP to .NET. The most common response from a given developer would likely be “I don’t know that language”. While there are always some developers who are fluent in more than one programming language, assuming competency across the board when looking for potential candidates will likely lengthen the time for searching.
• A “designer” does not mean a “developer” (and vice-versa). Hopefully, most employers and recruiters know this, but I still find some do not. Many developers who are extremely competent at developing mobile applications struggle with user interface design and the graphical nature of applications. Also note that being able to program in a language does not guarantee understanding the nuances of design for the platform. I point this out because of the simple fact that I regularly see employers/recruiters going after general programming knowledge as a way of “fast-tracking” the hiring process. By this I mean seeing companies looking for Objective-C or C# skills and minimizing mobile application development experience. All I can say here is – bad idea. If are comfortable with a large post-hire learning curve for your employee, then you are OK. If, however, you expect instant results, you will likely be disappointed.
• Be prepared to pay for employees skills. Sadly, there are some employers who are aware of everything I have said thus far but believe by recruiting generally for a mobile application developer they will get a “5 for the price of 1” hiring deal. Sorry folks – just like a company in need of hiring for natural language translation, the rule of thumb is “the more languages known, the higher the price”. Furthermore, the increasing hiring practice I have seen around “don’t tell them what we really expect from them until after we hire them” has resulted in successfully eliminating any employee retention. Bottom line – when you know what you need, be prepared to pay for what you need.

So, what can employers do to successfully recruit and retain mobile application developers? Here are a few suggestions based upon my experiences over the years -

• Have a mobile development vision before you start the hiring process. By vision, I mean something a bit more substantial than “create mobile applications”. Think about what applications you need, who will be using these applications, what platforms do you wish to target and when you need to go to market with them. This will not only help to define your job requirements; it will also help to engage with hiring prospects during the interview process and best identify hiring candidates. Remember – prospective employees are also interviewing view (not just the other way around). As I have advised many mobile developers seeking jobs, a company that does not understand what they need to hire for or why they are hiring is never a good thing from the employee perspective.
• Consider hiring tactically and working toward your strategy. This goes back to your mobile vision and prioritization. As an example, your immediate need may be for the iPhone. However, you want to expand your offerings to eventually include Android and Windows Phone. When hiring, you can build job requirements that look for iPhone development up front, but include an interest in developing for Android and Windows Phone in the future. When interviewing hiring candidates, you can discuss their openness toward learning about these platforms. Note: be prepared to develop a plan to support the learning process (training, time to learn, etc) and to discuss this with prospective candidates. There is nothing that turns off a potential development hire quicker than the feeling that an employee just expects them to learn something on their own with no support. By taking this approach, you will be able to identify candidates that are genuinely interested in mobile application development as a career and see you as a company to work with (not just work for) as a career.
• Remember the non-technical skills in addition to technical skills. Even a skilled programmer in a language and/or platform does not guarantee success if the person being hired lacks “higher-level” skills. As an example, I have heard countless tales of perspective candidates who knew iPhone development inside-out – as long as we were talking games development. For a company wanting to build line of business applications that include domain knowledge and integration into complex enterprise architectures, hiring this person typically results in an entirely different learning curve from both a technical and business perspective. Be sure to include such job requirements up front to avoid a lot of time spent interviewing candidates that don’t meet your needs. Also be sure to include such discussions with candidates during the interview process. I know of at least several instances where candidate screens were entirely focused on low-level knowledge of development, only to discover that the now-hired employee had no knowledge of integrating with business systems.
• It is a “buyers market”… and you are not the buyer. As hard as this may seem to accept, the demand for skilled mobile application developers is very high, and the supply is quite low. The higher you set the bar for job requirements, the harder it will be to find qualified candidates. Plan for a protracted employee search and hope to be pleasantly surprised if you find someone quickly. Do not wait until the last minute to start a candidate search.

In the end, employers, I give you this feedback and suggestions not to really “lower your standards”, but to adjust them. It will benefit not only yourselves, but the potential candidates to fulfill your employment needs. I just couldn’t pass up on the Jon Lovitz reference, though

• Versus the spread – 2 wins, 6 losses
• Straight-up winners – 3 wins, 5 losses

I’m avoiding the painful details of last week. I’ve decided my motto is don’t look back; look ahead. That being said, I now face to conference championship games that I wouldn’t touch with a ten-foot pole in the real betting world. This isn’t reality, though, so here goes my picks -

• Green Bay (-3.5) at Chicago
  This is Game 1 of the “Really Crappy Turf Weekend”. Soldier Field is a wreck. I do believe there is one truth about poor field conditions – they help offenses. Defensive lineman can’t plant for blocking/rushing, and cover men can’t break on routes. With that in mind, it comes down to the two offenses. Sorry Bears fans – as long as Jay Cutler is only a throw away from disaster, I can’t get behind you. As well as the Bears did last weekend, there will still a couple of “WHAT THE —- ARE YOU THINKING, CUTLER?!?” throws. Luckily, they weren’t caught. I think the Bears have the potential for some success on the ground, but not “150+ rushing yards” success.
  On the Packers side of things, Aaron Rodgers is playing in a different dimension right now – a dimension that allows him to see and do things that are simply not possible to the rest of us in three-dimensional space. I heard a statistic the other day that dumbfounded me. Last week, the Falcons had a free blitzer 15 times against the Packers (that means that 15 times, someone came in clean on Rodgers). Rodgers went 11 for 15 passing in those situations. That’s just not right, man… just not right. Green Bay should be able to deal with the Bears defense enough to let Rodgers be successful; maybe not 300+ yards successful, but successful enough to say…

  My Pick: Green Bay to cover the spread and win on the field.
  

• New York Jets (+3.5) at Pittsburgh
  Welcome to Game 2 of the “Really Crappy Turf Weekend”. Heinz Field is really not much better than Soldier Field this weekend. Again, offense has the advantage. For the Jets, the on-again, off-again rushing game is key. New York can’t afford to put Mark Sanchez in a position to have to carry them. They did this last week; Sanchez never had to play from behind. The problem for the Jets this time, though, is playing against a Pittsburgh defense that is WAY better, WAY more physical and WAY more experienced than the Patriots defense of last week.
  For Pittsburgh, they pose a unique challenge to the Jets defense this playoff season. So far, the Jets have played against two pure pocket-passers in Peyton Manning and Tom Brady. Credit the Jets for recognizing that blitzing is not the answer to everything, choosing instead a patient approach with a straight-up rush and excellent coverage. This week, though, you face Big Ben, New York. You face a quarterback that is as dangerous outside of the pocket as he is inside of the pocket. This is going to lead to some very interesting coverage challenges. Combine this with what I believe to be a more consistent (if not spectacular) rushing attack by the Steelers and I can only come to the conclusion that…

  My Pick: Pittsburgh to cover the spread and win on the field.

There you have it, folks. Stay tuned to see if I can change my prognosticating fortunes…

As someone who has worked with mobile device in the enterprise for a number of years, I can’t tell you how many times fragmentation has created havoc at the enterprise level in terms of providing users support or even access to enterprise systems (email, IM, file access, etc). Early on, it was just the expansion of platform variety that caused the problems. Today, it is nearly impossible for a business to simply say “you have to have <device x> in order to get…”. I have witnessed countless businesses who tried this approach, only to have to later change direction from too much pressure from executives and workers. Supporting multiple device platforms, however, was only the beginning.

Windows Mobile (or so it was named back in the day) was the first mobile OS that I worked with that had fragmentation within a single platform. As a matter of fact, it suffered at times from “fragmentation within fragmentation”. You see, there was the “Smartphone” version of the platform (eventually this became known as the “Standard Edition”) and the “Pocket PC” version (eventually known as “Professional”). Each had different capabilities and limitations. Some of these impacted developers creating applications, while others affected IT organizations trying to secure and configure devices to meet business guidelines. Add to all this confusion new versions of the operating system that often did not reach existing devices (mostly due to device manufacturers and carriers not wanting the updates to see the light of day), and the Windows Mobile platform was a constant source of confusion for IT support. Amazingly, I now look at the current state of Android and I am feeling a strong sense of history repeating itself, this time with Google playing the role of Microsoft. There are a couple of reasons for my thoughts here.

First, you have the breakneck pace of Android releases. This is actually happening at a far quicker pace than Windows Mobile updates ever happened. Each release introduces new features. Google has started to also take into account enterprise needs as well, with better Microsoft Exchange server support (including mailbox policies). This is great on the surface, but now factor in the device manufacturers and carriers once again taking their time to release the new OS versions to users and – well, here we go again. Add to this Google’s recent inferences that Android 3.0 is a “tablet-specific” OS and my brain immediately thinks “Smartphone/Pocket PC” all over again. Most amazing to me – Google seems to be oblivious to the risks that this current situation brings forth.

Microsoft’s mobile strategy was by and large the undoing of Windows Mobile, in my opinion. While there was a lot of user dissatisfaction around the operating system, Microsoft eventually lost the backing of the enterprise. Corporate IT was a major backer of Windows Mobile for quite some time, with the combination of enterprise-focused functionality and tremendous configurability and security options making it the “phone of choice” for many organizations. The fragmentation issue became too much to deal with over time, however, and when coupled with pressures from the user base led many IT folks to submit. Windows Phone 7 is the ultimate testament to the problems of Windows Mobile – it is a platform wholly-focused on avoiding the platform fragmentation issues of the past.

Android seems to be rapidly moving to a situation where the combination of user dissatisfaction over the lack of OS updates and IT frustration over the complications created by platform fragmentation could find Google witnessing some serious abandonment. Mind you, the question here is not about how good Android is as an operating system; it is about how good the platform and partner ecosystem are. As a developer, I have often reminded people “even if you have created the greatest application ever written, without user and IT acceptance it is nothing”. Google needs to be very careful of the path they are following – the path has led to a dead end in the past, and there is nothing to prove that history won’t repeat itself.

• I picked the Saints (-10) to beat the Seahawks, but not cover the spread.
  OK, so I didn’t see this one coming. I thought it was going to be close, with the Super Bowl experience winning out. I didn’t expect to see Marshawn Lynch pull a Lou Ferrigno/Incredible Hulk impression.
• I picked the Colts (-2.5) to top the Jets on the field and cover.
  This could’ve gone either way. I think the lesson learned is that Peyton Manning’s best years may be behind him. By that I don’t mean him – I mean the supporting cast around him. It is now becoming more evident that he can’t do it on his own.
• I picked the Chiefs (+3) in the upset over the Ravens.
  Did someone deliver a collective lobotomy to the Chiefs before kickoff? I have never seen a team looking so much like they had no clue of who they were playing. The term “deer in the headlights” has never been more appropriate. Man – did I blow this one.
• Green Bay (+2.5) to win and cover over the Eagles.
  At least there’s one game that I looked smart on.

So now it’s time to go out on a limb and pick next week’s games. Here’s to hoping I don’t look so bad two weeks in a row…

Alright then. I’ve climbed back out on the prognostication limb. Please don’t let it break…